firstDaisy Diff compare report.
Click on the changed parts for a detailed description. Use the left and right arrow keys to walk through the modifications.
last 

Protection Profile for Application SoftwareMobile Device Fundamentals

This page is best viewed with JavaScript enabled!

NIAP Logo
Version: 13.43
20212022-1009-07

National Information Assurance Partnership12

NIAP

Revision History

VersionDateComment
v 1.020142013-10-2021Initial releaseRelease
v 1.12014-1101-05Addition to TLS cipher suite selections
v 1.22016-04-22Added server-side TLS requirements (selection-based)

Multiple clarification based on NIAP TRRT inquiries

Refactored FDP_DEC_EXT.1 into separate components
v 1.32019-03-01Incorporated available Technical Decisions

Refactored FPT_TUD

Added a selection to FTP_DIT

Moved SWID Tags requirement

Leveraged TLS Package

Added equivalency section
v 1.42021-10-07Incorporated applicable Technical Decisions

Updated to TLS FP 1.1

Incorporated SSH FP 1.0 12
Typographical changes and additional clarifications in application notes. Removed

assignment from FCS_TLS_EXT.1 and limited testing to those ciphersuites in both

FCS_TLS_EXT.1 and FCS_TLS_EXT.2.
2.02015-09-14Included changes based on Technical Rapid Response Team Decisions. Clarified many

requirements and evaluation activities. Mandated objective requirements:Application Access Control (FDP_ACF_EXT.1.2)VPN Information Flow Control (FDP_IFC_EXT.1) Added new objective requirements:Suite B cryptography for IEEE 802.11Certificate enrollmentProtection of additional key material typesHeap overflow protectionBluetooth requirementsCryptographic operation services for applicationsRemote Attestation (FPT_NOT_EXT.1) Added transition dates for some objective requirements. Included

hardware-isolated REK and key storage selections. Allowed key derivation by

REK. Clarified FTP_ITC_EXT.1 and added FDP_UPC_EXT.1. Mandated HTTPS and

TLS for application use. (FDP_UPC_EXT.1) Removed Dual_EC_DRBG as an approved

DRBG. Adopted new TLS requirements. Mandated TSF Wipe upon authentication

failure limit and required number of authentication failures be maintained across

reboot. Clarified Management Class. Included more domain isolation

discussion and tests. Updated Audit requirements and added Auditable Events

table. Added SFR Category Mapping Table. Updated Use Case

Templates. Moved Glossary to Introduction.
3.02015-09-17Included changes based on Technical Rapid Response Team Decisions. Clarified

many requirements and evaluation activities. Mandated objective requirements:Generation of Audit Records (FAU_GEN.1)Audit Storage Protection (FAU_STG.1)Audit Storage Overwrite (FAU_STG.4)Lock Screen DAR (FDP_DAR_EXT.2)Discard Bluetooth Connection Attempts from Bluetooth Addresses with Existing

Connection (FIA_BLT_EXT.3)JTAG Disablement (FPT_JTA) Added new objective requirements:Application BackupBiometric Authentication FactorAccess ControlUser AuthenticationBluetooth Encryption WLAN client requirements moved to Extended Package for WLAN Client. Added

SFRs to support BYOD Use Case BYOD Use Case Updated key destruction SFR

3.12017-04-05Included changes based on Technical Rapid Response Team Decisions and incorporated

Technical Decisions. Modified biometric requirements: FIA_UAU.5 - Added iris, face, voice and vein as supported modalities, in addition

to fingerprint (allowed in version 3)FIA_BMG_EXT.1.1 - Clarified AA to specify that vendor evidence is acceptable and

expectations of evidence provided. FIA_BMG_EXT.1.2 - SAFAR was changed to an assignment of a SAFAR no greater than

1:500. FIA_AFL_EXT.1 - Updated to allow each biometric modality to utilize an individual

or shared counter. FCS_TLSC_EXT.1.1 - Removed TLS ciphersuites that utilized SHA1 and updated

optional ciphersuites to be uniformed across PPs. FCS_STG_EXT.2.2 - Modified to

require long term trusted channel key material be encrypted by an approved method.

FIA_UAU_EXT.1.1 - Modified to allow the long term trusted channel key material to be

available prior to password being entered at start-up.
3.22021-04-15Removed TLS SFRs and utilized TLS Functional Package Removed Bluetooth SFRs

and utilized Bluetooth Module. Bluetooth SFR moved to Implementation Dependent.

FPT_TUD_EXT.4.2 renumbered to
3.32022-09-12Integrated Biometrics cPP Module, Included changes based on Technical Rapid Response Team Decisions and open issues from GitHub.Removed biometric definitions from Tech TermsRemoved FDP_PBARemoved FIA_BMGUpdated FIA_UAU.5 to support bio cPP moduleMoved FTA_TAB.1 to mandatoryMoved FAU_SAR.1 to mandatoryAdded ECDUpdated WLAN Client reference from Extended Package to ModuleRemoved Diffie-Hellman group 14 selection from FCS_CKM.1.1 and FCS_CKM.2.1/UNLOCKED

Contents

1Introduction1.1OverviewObjectives of Document1.2Terms1.2.1Common Criteria Terms1.2.2Technical Terms1.3Compliant Targets of Evaluation1.3.1TOE Boundary1.4Use Cases1.5Platforms with Specific EAs2Conformance Claims3Security Problem DescriptionDefinition3.1Threats3.2Assumptions3.3Organizational Security Policies4Security Objectives4.1Security Objectives for the TOE4.2Security Objectives for the Operational Environment4.3Security Objectives Rationale5Security Requirements5.1Security Functional Requirements5.1.1Class: Security Audit (FAU)5.1.2Class: Cryptographic Support (FCS)5.1.23Class: Cryptographic Storage (FCS_STG_EXT)5.1.4Class: User Data Protection (FDP)5.1.3Security Management (FMT5Class: Identification and Authentication (FIA)5.1.4Privacy (FPR6Class: Security Management (FMT)5.1.57Class: Protection of the TSF (FPT)5.1.68Class: TOE Access (FTA)5.1.9Class: Trusted Path/Channel Channels (FTP)5.1.710TOE Security Functional Requirements Rationale5.2Security Assurance Requirements5.2.1Class ASE: Security Target5.2.2Class ADV: Development5.2.3Class AGD: Guidance Documentation5.2.4Class ALC: Life-cycle Support5.2.5Class ATE: Tests5.2.6Class AVA: Vulnerability AssessmentAppendix A - Optional RequirementsA.1Strictly Optional Requirements A.1.1Cryptographic Support (FCSClass: Identification and Authentication (FIA)A.2Objective Requirements A.2.1Class: Security Audit (FAU)A.2.2Class: Cryptographic Support (FCS)A.2.3Class: User Data Protection (FDP)A.2.4Class: Identification and Authentication (FIA)A.2.5Class: Security Management (FMT)A.2.6Class: Protection of the TSF (FPT)A.3Implementation-Based dependent Requirements Appendix B - Selection-Based based Requirements B.1Class: Cryptographic Support (FCS)B.2Identification and Authentication (FIAClass: User Data Protection (FDP)B.3Class: Protection of the TSF (FPT)Appendix C - Implicitly Satisfied RequirementsAppendix D - Entropy Documentation and And AssessmentCD.1Design DescriptionCD.2Entropy JustificationCD.3Operating ConditionsCD.4Health TestingAppendix D - Application Software Equivalency GuidelinesD.1IntroductionD.2Approach to Equivalency AnalysisD.3Specific Guidance for Determining Product Model EquivalenceD.4Specific Guidance for Determining Product Version EquivalenceD.5Specific Guidance for Determining Platform EquivalenceD.5.1Platform Equivalence—Hardware/Virtual Hardware PlatformsD.5.2Platform Equivalence—OS PlatformsD.5.3Software-based Execution Environment Platform EquivalenceD.6Level of Specificity for Tested Configurations and Claimed Equivalent ConfigurationsAppendix E - AcronymsAppendix F - BibliographyAppendix G - Acknowledgments

1 Introduction

1.1

Overview

Objectives of Document

The scope of this Protection Profile (PP) is to describe the security functionality of application software mobile devices in terms of [CC] and to define functional and assurance requirements for such software. In recent years, software attacks have shifted from targeting operating systems to targeting applications. This has been the natural response to improvements in operating system security and development processes. As a result, it is paramount that the security of applications be improved to reduce the risk of compromise. devices. , Protection Profiles
Target of Evaluation (TOE)
The product under evaluation. (ASLR) an application
Sensitive Data
Sensitive data
Application (app)
Software that runs on a platform and performs tasks on behalf of the user or owner of the platform, as well as its supporting documentation. The terms TOE and application are interchangeable in this document.
Application Programming Interface (API)
A specification of routines, data structures, object classes, and variables that allows an application to make use of services provided by another software component, such as a library. APIs are often provided for a set of libraries included with the platform.
Credential
Data that establishes the identity of a user, e.g. a cryptographic key or password.
Data Execution Prevention (DEP)
An anti-exploitation feature of modern operating systems executing on modern computer hardware, which enforces a non-execute permission on pages of memory. DEP prevents pages of memory from containing both data and instructions, which makes it more difficult for an attacker to introduce and execute code.
Developer
An entity that writes application software. For the purposes of this document, vendors and developers are the same.
Mobile Code
Software transmitted from a remote system for execution within a limited execution environment on the local system. Typically, there is no persistent installation and execution begins without the user's consent or even notification. Examples of mobile code technologies include JavaScript, Java applets, Adobe Flash, and Microsoft Silverlight.
Operating System (OS)
Software that manages hardware resources and provides services for applications.
Personally Identifiable Information (PII)
Any information about an individual maintained by an agency, including, but not limited to, education, financial transactions, medical history, and criminal or employment history and information which can be used to distinguish or trace an individual's identity, such as their name, social security number, date and place of birth, mother’s maiden name, biometric records, etc., including any other personal information which is linked or linkable to an individual. [OMB]
Platform
The environment in which application software runs. The platform can be an operating system, hardware environment, a software based execution environment, or some combination of these. These types platforms may also run atop other platforms. must minimally include PII, credentials, and keys. Sensitive data shall be identified in the application’s TSS by the ST author. An anti-exploitation feature that places a value on the stack at the start of a function call, and checks that the value is the same at the end of the function call. This is also referred to as Stack Guard, or Stack Canaries.
Vendor
An entity that sells application software. For purposes of this document, vendors and developers are the same. Vendors are responsible for maintaining and updating application software.

1.3 Compliant Targets of Evaluation

The requirements in this document apply to application software which runs on any type of platform. Some application types are covered by more specific PPs, which may be expressed as PP-Modules of this PP. Such applications are subject to the requirements of both this PP and the PP-Module that addresses their special functionality. PPs for some particularly specialized applications may not be expressed as PP-Modules at this time, though the requirements in this document should be seen as objectives for those highly specialized applications.

Although the requirements in this document apply to a wide range of application software, consult guidance from the relevant national schemes to determine when formal Common Criteria evaluation is expected for a particular type of application. This may vary depending upon the nature of the security functionality of the application.

1.3.1 TOE Boundary

The application, which consists of the software provided by its vendor, is installed onto the platform(s) it operates on. It executes on the platform, which may be an operating system (Figure 1), hardware environment, a software based execution environment, or some combination of these (Figure 2). Those platforms may themselves run within other environments, such as virtual machines or operating systems, that completely abstract away the underlying hardware from the application. The TOE is not accountable for security functionality that is implemented by platform layers that are abstracted away. Some evaluation activities are specific to the particular platform on which the application runs, in order to provide precision and repeatability. The only platforms currently recognized by the AppPP are those specified in SFR Evaluation Activities. To test on a platform for which there are no EAs, a Vendor should contact NIAP with recommended EAs. NIAP will determine if the proposed platform is appropriate for the PP and accept, reject, or develop EAs as necessary in coordination with the technical community.

Applications include a diverse range of software such as office suites, thin clients, PDF readers, downloadable smartphone apps, and apps running in a cloud container. The TOE includes any software in the application installation package, even those pieces that may extend or modify the functionality of the underlying platform, such as kernel drivers. Many platforms come bundled with applications such as web browsers, email clients and media players and these too should be considered subject to the requirements defined in this document although the expectation of formal Common Criteria evaluation depends upon the national scheme. BIOS and other firmware, the operating system kernel, and other systems software (and drivers) provided as part of the platform are outside the scope of this document.


Figure 1: TOE as an Application and Kernel Module Running on an Operating System


Figure 2: TOE as an Application Running in an Execution Environment Plus Native Code

1.4 Use Cases

Requirements in this Protection Profile are designed to address the security problem in the following use cases. These use cases are intentionally very broad, as many specific use cases exist for application software. Many applications may be used in combinations of these broad use cases, and evaluation against PP-Modules of this PP, when available, may be most appropriate for some application types.
[USE CASE 1] Content Creation
The application allows a user to create content, saving it to either local or remote storage. Example content includes text documents, presentations, and images.
[USE CASE 2] Content Consumption
The application allows a user to consume content, retrieving it from either local or remote storage. Example content includes web pages and video.
[USE CASE 3] Communication
The application allows for communication interactively or non-interactively with other users or applications over a communications channel. Example communications include instant messages, email, and voice.

1.5 Platforms with Specific EAs

This PP includes platform-specific EAs for the below-listed operating system platforms. For "bare-metal" applications, applications that run on other OS platforms, and applications that run in software-based execution environments contact the Technical Community for guidance.

2 Conformance Claims

Conformance Statement
An ST must claim exact conformance to this PP, as defined in the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional SFRs (dated May 2017).
CC Conformance Claims
This PP is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version 3.1, Revision 5.
PP Claim
This PP does not claim conformance to any other Protection Profile.

The following PPs and PP-Modules are allowed to be specified in a PP-Configuration with this PP.

  • Protection Profile for Mobile Device Management Version 4.0
  • PP-Module for File Encryption, Version 1.0
  • PP-Module for File Encryption Enterprise Management, Version 1.0
  • PP-Module for VPN Clients, Version 2.2
  • PP-Module for VPN Clients, Version 2.3
  • PP-Module for Endpoint Detection and Response, Version 1.0
  • PP-Module for Host Agent, Version 1.0
  • PP-Module for Voice and Video over IP (VVoIP), Version 1.0
  • PP-Module for Email Clients, Version 1.0
  • Package Claim

    3 Security Problem Description

    The security problem is described in terms of the threats that the TOE is expected to address, assumptions about the operational environment, and any organizational security policies that the TOE is expected to enforce.

    3.1 Threats

    This assurance standard specifies information security requirements for Mobile Devices for use in an enterprise. A Mobile Device in the context of this assurance standard is a device, which is composed of a hardware platform and its system software. The device typically provides wireless connectivity and may include software for functions like secure messaging, email, web, VPN connection, and VoIP (Voice over IP), for access to the protected enterprise network, enterprise data and applications, and for communicating to other Mobile Devices.


    Figure 1 illustrates the network operating environment of the Mobile Device.




    Figure 1: Mobile Device Network Environment


    Examples of a "Mobile Device" that should claim conformance to this Protection Profile include smartphones, tablet computers, and other Mobile Devices with similar capabilities.


    The Mobile Device provides essential services, such as cryptographic services, data-at-rest protection, and key storage services to support the secure operation of applications on the device. Additional security features such as security policy enforcement, application mandatory access control, anti-exploitation features, user authentication, and software integrity protection are implemented in order to address threats.


    This assurance standard describes these essential security services provided by the Mobile Device and serves as a foundation for a secure mobile architecture. The wireless connectivity shall be validated against the PP-Module for Wireless LAN Clients, version 1.0. If the mobile device contains Bluetooth functionality (i.e., has Bluetooth hardware), the Bluetooth connectivity shall be evaluated against the PP-Module for Bluetooth, version 1.0. As illustrated in Figure 2, it is expected that a typical deployment would also include either third-party or bundled components. Whether these components are bundled as part of the Mobile Device by the manufacturer or developed by a third-party, they must be separately validated against the related assurance standards such as the PP-Module for MDM Agent, PP-Module for VPN Client, PP-Module for VVoIP, and cPP-Module for Biometrics. It is the responsibility of the architect of the overall secure mobile architecture to ensure validation of these components. Additional applications that may come pre-installed on the Mobile Device that are not validated are considered to be potentially flawed, but not malicious. Examples include email client and web browser.




    Figure 2: Optional Additional Mobile Device Components

    1.4 Use Cases

    The Mobile Device may be operated in a number of use cases. use-case-appendix provides use case templates that list those selections, assignments, and objective requirements that best support the use cases identified by this Protection Profile. In addition to providing essential security services, the Mobile Device includes the necessary security functionality to support configurations for these various use cases. Each use case may require additional configuration and applications to achieve the desired security. A selection of these use cases is elaborated below.

    Several of the use case templates include objective requirements that are strongly desired for the indicated use cases. Readers can expect those requirements to be made mandatory in a future revision of this protection profile, and industry should aim to include that security functionality in products in the near-term.

    As of publication of this version of the Protection Profile, meeting the requirements in is necessary for all use cases.
    [USE CASE 1] Enterprise-owned device for general-purpose enterprise use and limited personal use
    An enterprise-owned device for general-purpose business use is commonly called Corporately Owned, Personally Enabled (COPE). This use case entails a significant degree of enterprise control over configuration and, possibly, software inventory. The enterprise elects to provide users with Mobile Devices and additional applications (such as VPN or email clients) in order to maintain control of their Enterprise data and security of their networks. Users may use Internet connectivity to browse the web or access corporate mail or run enterprise applications, but this connectivity may be under significant control of the enterprise.
    [USE CASE 2] Enterprise-owned device for specialized, high security use
    An enterprise-owned device with intentionally limited network connectivity, tightly controlled configuration, and limited software inventory is appropriate for specialized, high-security use cases. For example, the device may not be permitted connectivity to any external peripherals. It may only be able to communicate via its Wi-Fi or cellular radios with the enterprise-run network, which may not even permit connectivity to the Internet. Use of the device may entail compliance with policies that are more restrictive than those in any general-purpose use case, yet may mitigate risks to highly sensitive information. As in the previous case, the enterprise will look for additional applications providing enterprise connectivity and services to have a similar level of assurance as the platform.
    [USE CASE 3] Personally-owned device for personal and enterprise use
    A personally-owned device that is used for both personal activities and enterprise data is commonly called Bring Your Own Device (BYOD). The device may be provisioned for access to enterprise resources after significant personal usage has occurred. Unlike in the enterprise-owned cases, the enterprise is limited in what security policies it can enforce because the user purchased the device primarily for personal use and is unlikely to accept policies that limit the functionality of the device. However, because the enterprise allows the user full (or nearly full) access to the enterprise network, the enterprise will require their own security controls to ensure that enterprise resources are protected from potential threats posed by the personal activities on the device. These controls could potentially be enforced by a separation mechanism built-in to the device itself to distinguish between enterprise and personal activities, or by a third-party application that provides access to enterprise resources and leverages security capabilities provided by the mobile device. Based upon the operational environment and the acceptable risk level of the enterprise, those security functional requirements outlined in of this PP along with the selections in the Use Case 3 template defined in Appendix F - Use Case Templates are sufficient for the secure implementation of this BYOD use case.
    [USE CASE 4] Personally-owned device for personal and limited enterprise use
    A personally-owned device that is used for both personal activities and enterprise data is commonly called Bring Your Own Device (BYOD). This device may be provisioned for limited access to enterprise resources such as enterprise email. Because the user does not have full access to the enterprise or enterprise data, the enterprise may not need to enforce any security policies on the device. However, the enterprise may want secure email and web browsing with assurance that the services being provided to those clients by the Mobile Device are not compromised. Based upon the operational environment and the acceptable risk level of the enterprise, those security functional requirements outlined in Section 5 Security Requirements of this PP are sufficient for the secure implementation of this BYOD use case.

    2 Conformance Claims

    Conformance Statement


    CC Conformance Claims


    PP Claims


    Package Claims


    3 Security Problem Definition

    3.1 Threats

    Mobile devices are subject to the threats of traditional computer systems along with those entailed by their mobile nature. The threats considered in this PP are those of network eavesdropping, network attacks, physical access, malicious or flawed applications, persistent presence, and backup as detailed in the following sections.

    T.MALICIOUS_APP
    Applications loaded onto the Mobile Device may include malicious or exploitable code. This code could be included intentionally or unknowingly by the developer, perhaps as part of a software library. Malicious apps may attempt to exfiltrate data to which they have access. They may also conduct attacks against the platform’s system software, which will provide them with additional privileges and the ability to conduct further malicious activities. Malicious applications may be able to control the device's sensors (GPS, camera, microphone) to gather intelligence about the user's surroundings even when those activities do not involve data resident or transmitted from the device. Flawed applications may give an attacker access to perform network-based or physical attacks that otherwise would have been prevented
    T.NETWORK_ATTACK
    An attacker is positioned on a wireless communications channel or elsewhere on the network infrastructure. Attackers may engage in initiate communications with the application software Mobile Device or alter communications between the application software Mobile Device and other endpoints in order to compromise it.the Mobile Device. These attacks include malicious software update of any applications or system software on the device. These attacks also include malicious web pages or email attachments, which are usually delivered to devices over the network.
    T.NETWORK_EAVESDROP
    An attacker is positioned on a wireless communications channel or elsewhere on the network infrastructure. Attackers may monitor and gain access to data exchanged between the application Mobile Device and other endpoints.
    T.
    LOCAL_ATTACKAn attacker can act through unprivileged software on the same computing platform on which the application executes. Attackers may provide maliciously formatted input to the application in the form of files or other local communications
    PERSISTENT_PRESENCE
    Persistent presence on a device by an attacker implies that the device has lost integrity and cannot regain it. The device has likely lost this integrity due to some other threat vector, yet the continued access by an attacker constitutes an on-going threat in itself. In this case, the device and its data may be controlled by an adversary as well as by its legitimate owner.
    T.PHYSICAL_ACCESS
    An attacker, with physical access, may try attempt to access sensitive data at rest.user data on the Mobile Device including credentials. These physical access threats may involve attacks, which attempt to access the device through external hardware ports, impersonate the user authentication mechanisms, through its user interface, and also through direct and possibly destructive access to its storage media. Note: Defending against device re-use after physical compromise is out of scope for this Protection Profile.

    3.2 Assumptions

    A.
    PLATFORM
    The TOE relies upon a trustworthy computing platform with a reliable time clock for its execution. This includes the underlying platform and whatever runtime environment it provides to the TOE.
    A.PROPER_USER
    The user of the application software is not willfully negligent or hostile, and uses the software in compliance with the applied enterprise security policy.
    A.PROPER_ADMIN
    The administrator of the application software is not careless,
    CONFIG
    It is assumed that the TOE’s security functions are configured correctly in a manner to ensure that the TOE security policies will be enforced on all applicable network traffic flowing among the attached networks.
    A.NOTIFY
    It is assumed that the mobile user will immediately notify the administrator if the Mobile Device is lost or stolen.
    A.PRECAUTION
    It is assumed that the mobile user exercises precautions to reduce the risk of loss or theft of the Mobile Device.
    A.PROPER_USER
    Mobile Device users are not willfully negligent or hostile, and administers use the software in compliance with the applied enterprise device within compliance of a reasonable Enterprise security policy.

    3.3 Organizational Security Policies

    This document does not define any additional OSPs.

    4 Security Objectives

    4.1 Security Objectives for the TOE

    O.
    INTEGRITY
    Conformant TOEs ensure the integrity of their installation and update packages, and also leverage execution environment-based mitigations. Software is seldom, if ever, shipped without errors. The ability to deploy patches and updates to fielded software with integrity is critical to enterprise network security. Processor manufacturers, compiler developers, execution environment vendors, and operating system vendors have developed execution environment-based mitigations that increase the cost to attackers by adding complexity to the task of compromising systems. Application software can often take advantage of these mechanisms by using APIs provided by the runtime environment or by enabling the mechanism through compiler or linker options.
    O.QUALITY
    To ensure quality of implementation, conformant TOEs leverage services and APIs provided by the runtime environment rather than implementing their own versions of these services and APIs. This is especially important for cryptographic services and other complex operations such as file and media parsing. Leveraging this platform behavior relies upon using only documented and supported APIs.
    O.MANAGEMENT
    To facilitate management by users and the enterprise, conformant TOEs provide consistent and supported interfaces for their security-relevant configuration and maintenance. This includes the deployment of applications and application updates through the use of platform-supported deployment mechanisms and formats, as well as providing mechanisms for configuration. This also includes providing control to the user regarding disclosure of any PII.
    O.PROTECTED_
    AUTH
    To address the issue of loss of confidentiality of user data in the event of loss of a Mobile Device (T.PHYSICAL_ACCESS), users are required to enter an authentication factor to the device prior to accessing protected functionality and data. Some non-sensitive functionality (e.g., emergency calling, text notification) can be accessed prior to entering the authentication factor. The device will automatically lock following a configured period of inactivity in an attempt to ensure authorization will be required in the event of the device being lost or stolen. Authentication of the endpoints of a trusted communication path is required for network access to ensure attacks are unable to establish unauthorized network connections to undermine the integrity of the device. Repeated attempts by a user to authorize to the TSF will be limited or throttled to enforce a delay between unsuccessful attempts.
    O.CONFIG
    To ensure a Mobile Device protects user and enterprise data that it may store or process, conformant TOEs will provide the capability to configure and apply security policies defined by the user and the Enterprise Administrator. If Enterprise security policies are configured these must be applied in precedence of user specified security policies.
    O.INTEGRITY
    To ensure the integrity of the Mobile Device is maintained conformant TOEs will perform self-tests to ensure the integrity of critical functionality, software/firmware and data has been maintained. The user shall be notified of any failure of these self-tests. This will protect against the threat T.PERSISTENT. To address the issue of an application containing malicious or flawed code (T.MALICIOUS_APP), the integrity of downloaded updates to software/firmware will be verified prior to installation/execution of the object on the Mobile Device. In addition, the TOE will restrict applications to only have access to the system services and data they are permitted to interact with. The TOE will further protect against malicious applications from gaining access to data they are not authorized to access by randomizing the memory layout.
    O.PRIVACY
    In a BYOD environment (use cases 3 and 4), a personally-owned mobile device is used for both personal activities and enterprise data. Enterprise management solutions may have the technical capability to monitor and enforce security policies on the device. However, the privacy of the personal activities and data must be ensured. In addition, since there are limited controls that the enterprise can enforce on the personal side, separation of personal and enterprise data is needed. This will protect against the T.MALICIOUS_APP and T.PERSISTENT_PRESENCE threats.
    O.PROTECTED_COMMS
    To address the network eavesdropping (T.NETWORK_EAVESDROP) and network attack (T.NETWORK_ATTACK) threats described in , concerning wireless transmission of Enterprise and user data and configuration data between the TOE and remote network entities, conformant TOEs will use a trusted communication path. The TOE must be capable of communicating using mutually authenticated TLS, EAP-TLS, HTTPS, 802.1X, and 802.11-2012. The TOE may optionally communicate using these standard protocols: IPsec, mutually-authenticated DTLS, or Bluetooth. These protocols are specified by RFCs that offer a variety of implementation choices. Requirements have been imposed on some of these choices (particularly those for cryptographic primitives) to provide interoperability and resistance to cryptographic attack. While conformant TOEs must support all of the choices specified in the ST including any optional SFRs defined in this PP, they may support additional algorithms and protocols. If such additional mechanisms are not evaluated, guidance must be given to the administrator to make clear the fact that they were not evaluated.
    O.STORAGE
    To address the issue of loss of confidentiality of user data in the event of loss of physical control of the storage mediuma Mobile Device (T.PHYSICAL_ACCESS), conformant TOEs will use data-at-rest protection. This involves The TOE will be capable of encrypting data and keys stored by the TOE in order to on the device and will prevent unauthorized access to this data. This also includes unnecessary network communications whose consequence may be the loss of data.
    O.PROTECTED_COMMS
    To address both passive (eavesdropping) and active (packet modification) network attack threats, conformant TOEs will use a trusted channel for sensitive data. Sensitive data includes cryptographic keys, passwords, and any other data specific to the application that should not be exposed outside of the application.
    encrypted data.

    4.2 Security Objectives for the Operational Environment

    The following security objectives for the operational environment assist the TOE in correctly providing its security functionality. These track with the assumptions about the environment.
    OE.PLATFORM
    The TOE relies upon a trustworthy computing platform for its execution. This includes the underlying operating system and any discrete execution environment provided to the TOE.
    OE.PROPER_USER
    The user of the application software is not willfully negligent or hostile, and uses the software within compliance of the applied enterprise security policy.
    OE.PROPER_ADMIN
    The administrator of the application software is not careless, willfully negligent or hostile, and administers the software within compliance of the applied enterprise security policy
    OE.CONFIG
    TOE administrators will configure the Mobile Device security functions correctly to create the intended security policy
    OE.DATA_PROPER_USER
    Administrators take measures to ensure that mobile device users are adequately vetted against malicious intent and are made aware of the expectations for appropriate use of the device.
    OE.NOTIFY
    The Mobile User will immediately notify the administrator if the Mobile Device is lost or stolen.
    OE.PRECAUTION
    The mobile device user exercises precautions to reduce the risk of loss or theft of the Mobile Device.

    4.3 Security Objectives Rationale

    This section describes how the assumptions, threats, and organizational security policies map to the security objectives. NETWORKATTACKNETWORKATTACKPROTECTED_COMMS for integrity of transmitted dataMANAGEMENT for the ability to configure the application to defend against network attack.T.NETWORK_EAVESDROPCOMMSEAVESDROP for confidentiality of transmitted data.LOCALATTACK
    Table 1: Security Objectives Rationale
    Threat, Assumption, or OSPSecurity ObjectivesRationale
    T.MALICIOUS_​APPO.PROTECTED_COMMSAUTHThe threat T.MALICIOUS_APP is countered by O.AUTH as this provides the capability to authenticate the user and endpoints of a trusted path to ensure they are communicating with an authorized entity with appropriate privileges.
    O.CONFIGThe threat T.
    MALICIOUS_
    APP is countered by O.
    CONFIG as this provides
    the capability to configure and apply security policies to ensure the Mobile Device can protect user and enterprise data that it may store or process.
    O.INTEGRITYThe threat T.NETWORKMALICIOUS_ATTACKAPP is countered by O.INTEGRITY as this provides for the capability to perform self-tests to ensure the integrity of software that is installed onto the system from the network.O.MANAGEMENTcritical functionality, software/firmware and data has been maintained.
    O.PRIVACYThe threat T.MALICIOUS_APP is countered by O.PRIVACY as this provides separation and privacy between user activities.
    O.PROTECTED_​COMMSThe threat T.MALICIOUS_APP is countered by O.PROTECTED_COMMS as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted outside of the TOE.
    T.NETWORK_​ATTACKO.AUTHThe threat T.NETWORK_ATTACK is countered by O.
    AUTH as this provides
    authentication of the endpoints of a trusted communication path.
    O.CONFIGThe threat T.NETWORK_ATTACK is countered by O.CONFIG as this provides a secure configuration of the mobile device to protect data that it processes.
    O.PROTECTED_
    ​COMMSThe threat T.NETWORK_
    ATTACK is countered by O.PROTECTED_COMMS as this provides
    O.QUALITYThe objective O.QUALITY ensures use of mechanisms that provide protection against network-based attack.
    O.MANAGEMENTthe capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted outside of the TOE.
    T.NETWORK_​EAVESDROPO.AUTHThe threat T.NETWORK_EAVESDROP is countered by O.AUTH as this provides authentication of the endpoints of a trusted communication path.
    O.CONFIGThe threat T.NETWORK_EAVESDROP is countered by O.MANAGEMENTCONFIG as this provides for the ability to configure the application to protect the confidentiality of its transmitted dataa secure configuration of the mobile device to protect data that it processes.
    O.PROTECTED_​COMMSThe threat T.NETWORK_EAVESDROP is countered by O.PROTECTED_COMMS as this provides the capability to communicate using one (or more) standard protocols as a means to maintain the confidentiality of data that are transmitted outside of the TOE.
    T.PERSISTENT_​PRESENCEO.QUALITYINTEGRITYThe objective O.QUALITY protects against the use of mechanisms that weaken the TOE with regard to attack by other software on the platform.
    T.PHYSICAL_ACCESS

    O.PROTECTED_STORAGEThe objective O.PROTECTED_STORAGE protects against unauthorized attempts to access physical storage used by the TOE.
    A.PLATFORM

    OE.PLATFORMthreat T.PERSISTENT_PRESENCE is countered by O.INTEGRITY as this provides the capability to perform self-tests to ensure the integrity of critical functionality, software/firmware and data has been maintained.
    O.PRIVACYThe threat T.PERSISTENT_PRESENCE is countered by O.PRIVACY as this provides separation and privacy between user activities.
    T.PHYSICAL_​ACCESSO.AUTHThe threat T.PHYSICAL_ACCESS is countered by O.AUTH as this provides the capability to authenticate the user prior to accessing protected functionality and data.
    O.STORAGEThe threat T.PHYSICAL_ACCESS is countered by O.STORAGE as this provides the capability to encrypt all user and enterprise data and authentication keys to ensure the confidentiality of data that it stores.
    A.CONFIGOE.CONFIGThe operational environment objective OE.PLATFORMCONFIG is realized through A.PLATFORMCONFIG.
    A.PROPER_USERNOTIFYOE.PROPER_USERNOTIFYThe operational environment objective OE.PROPER_USERNOTIFY is realized through A.PROPER_USERNOTIFY.
    A.PRECAUTIONOE.PRECAUTIONThe operational environment objective OE.PRECAUTION is realized through A.PRECAUTION.
    A.PROPER_ADMIN​USEROE.PROPERDATA_ADMIN​PROPER_​USERThe operational environment objective OE.DATA_PROPER_ADMINUSER is realized through A.PROPER_ADMINUSER.

    5 Security Requirements

    This chapter describes the security requirements which have to be fulfilled by the product under evaluation. Those requirements comprise functional components from Part 2 and assurance components from Part 3 of [CC]. The following conventions are used for the completion of operations:

    5.1 Security Functional Requirements

    5.1.1 Class: Security Audit (FAU)

    FAU_GEN.1 Audit Data Generation

    The TSF shall be able to generate an audit record of the following auditable events:
    1. Start-up and shutdown of the audit functions
    2. All auditable events for the [not selected] level of audit
    3. All administrative actions
    4. Start-up and shutdown of the OS
    5. Insertion or removal of removable media
    6. Specifically defined auditable events in Table t-audit-mandatory
    7. [selection: Audit records reaching [assignment: integer value less than 100 ] percentage of audit capacity, Specifically defined auditable events in , [assignment: other auditable events derived from this Protection Profile ], no additional auditable events]
    Application Note: Administrator actions are defined as functions labeled as mandatory for FMT_MOF_EXT.1.2 (i.e. ‘M-MM’ in Table 6Table 6). If the TSF does not support removable media, number 4 is implicitly met.


    The TSF must generate an audit record for all events contained in Table t-audit-mandatory. Generating audit records for events in is currently objective. It is acceptable to include individual SFRs from in the ST, without including the entirety of .


    Table t-audit-mandatory Application Note:

    FPT_TST_EXT.1 – Audit of self-tests is required only at initial start-up. Since the TOE "transitions to non-operational mode" upon failure of a self-test, per FPT_NOT_EXT.1, this is considered equivalent evidence to an audit record for the failure of a self-test.


    FDP_DAR_EXT.1 - "None" must be selected, if the TOE utilizes whole volume encryption for protected data, since it is not feasible to audit when the encryption/decryption fails. If the TOE utilizes file-based encryption for protected data and audits when this encryption/decryption fails, then that auditable event should be selected.


    Application Note:

    If the audit event for FMT_SMF.1 is included in the ST, it is acceptable for the initiation of the software update to be audited without indicating the outcome (success or failure) of the update.

    Validation Guidelines:

    Rule #1
    The TSF shall record within each audit record at least the following information:
    1. Date and time of the event
    2. Type of event
    3. Subject identity
    4. The outcome (success or failure) of the event
    5. Additional information in Table t-audit-mandatory
    6. [selection: Additional information in , no additional information]
    Application Note: The subject identity is usually the process name/ID. The event type is often indicated by a severity level, for example, ‘info’, ‘warning’, or ‘error’.


    If no additional auditable events is selected in the second selection of FAU_GEN.1.1, then no additional information must be selected.


    For each audit event selected from in FAU_GEN.1.1 if additional information is required to be recorded within the audit record, it should be included in this selection.
    Validation Guidelines:

    Rule #1
    TSS
    The evaluator shall check the TSS and ensure that it lists all of the auditable events and provides a format for audit records. Each audit record format type must be covered, along with a brief description of each field. The evaluator shall check to make sure that every audit event type mandated by the PP is described and that the description of the fields contains the information required in FAU_GEN.1.2.


    Guidance
    The evaluator shall also make a determination of the administrative actions that are relevant in the context of this PP including those listed in the Management section. The evaluator shall examine the administrative guide and make a determination of which administrative commands are related to the configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements specified in the PP. The evaluator shall document the methodology or approach taken while determining which actions in the administrative guide are security relevant with respect to this PP. The evaluator may perform this activity as part of the activities associated with ensuring the AGD_OPE guidance satisfies the requirements.


    Tests
    The evaluator shall test the TOE’s ability to correctly generate audit records by having the TOE generate audit records for the events listed in the provided table and administrative actions. This should include all instances of an event. The evaluator shall test that audit records are generated for the establishment and termination of a channel for each of the cryptographic protocols contained in the ST. For administrative actions, the evaluator shall test that each action determined by the evaluator above to be security relevant in the context of this PP is auditable. When verifying the test results, the evaluator shall ensure the audit records generated during testing match the format specified in the administrative guide, and that the fields specified in FAU_GEN.1.2 are contained in each audit record.


    Note that the testing here can be accomplished in conjunction with the testing of the security mechanisms directly. For example, testing performed to ensure that the administrative guidance provided is correct verifies that AGD_OPE.1 is satisfied and should address the invocation of the administrative actions that are needed to verify the audit records are generated as expected.


    FAU_SAR.1 Audit Review

    The TSF shall provide [ the administrator ] with the capability to read [ all audited events and record contents ] from the audit records.
    Application Note: The administrator must have access to read the audit record, perhaps through an API or via an MDM Agent, which transfers the local records stored on the TOE to the MDM Server where the enterprise administrator may view them. If this requirement is included in the ST, function 32 must be included in the selection of FMT_SMF.1.
    The TSF shall provide the audit records in a manner suitable for the userto interpret the information.
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    The evaluation activity for this requirement is performed in conjunction with test for function 32 of FMT_SMF.1.

    FAU_STG.1 Audit Storage Protection

    The TSF shall protect the stored audit records in the audit trail from unauthorized deletion.
    The TSF shall be able to [ prevent ] unauthorized modifications to the stored audit records in the audit trail.
    TSS
    The evaluator shall ensure that the TSS lists the location of all logs and the access controls of those files such that unauthorized modification and deletion are prevented.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    • Test FAU_STG.1.2:1: The evaluator shall attempt to delete the audit trail in a manner that the access controls should prevent (as an unauthorized user) and shall verify that the attempt fails.
    • Test FAU_STG.1.2:2: The evaluator shall attempt to modify the audit trail in a manner that the access controls should prevent (as an unauthorized application) and shall verify that the attempt fails.

    FAU_STG.4 Prevention of Audit Data Loss

    The TSF shall [ overwrite the oldest stored audit records ] and [assignment: other actions to be taken in case of audit storage failure] if the audit trail is full.
    TSS
    The evaluator shall examine the TSS to ensure that it describes the size limits on the audit records, the detection of a full audit trail, and the actions taken by the TSF when the audit trail is full. The evaluator shall ensure that the actions results in the deletion or overwrite of the oldest stored record.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    5.1.2 Class: Cryptographic Support (FCS)

    This section describes how keys are generated, derived, combined, released and destroyed. There are two major types of keys: DEKs and KEKs. (A REK is considered a KEK.) DEKs are used to protect data (as in the DAR protection described in FDP_DAR_EXT.1 and FDP_DAR_EXT.2). KEKs are used to protect other keys – DEKs, other KEKs, and other types of keys stored by the user or applications. The following diagram shows an example key hierarchy to illustrate the concepts of this profile. This example is not meant as an approved design, but ST authors will be expected to provide a diagram illustrating their key hierarchy in order to demonstrate that they meet the requirements of this profile. Please note if biometric in accordance with the Biometric Enrollment and Verification, version 1.1 is selected in FIA_UAU.5.1, each BAF claimed in FIA_MBV_EXT.1.1 in the Biometric Enrollment and Verification, version 1.1 shall be illustrated in the key hierarchy diagram, to include a description of when and how the BAF is used to release keys. If hybrid is selected in FIA_UAU.5.1, meaning that a PIN or password must be used in conjunction with the BAF, this interaction shall be included.



    Figure 3: An Illustrative Key Hierarchy
    Evaluation Activities
    FDP_NET_EXT.1
    TSS
    None.

    Guidance
    None.

    Tests
    The evaluator shall perform the following tests:
    Platforms:Android...
    If "no network communication" is selected, the evaluator shall ensure that the application's AndroidManifest.xml file does not contain a uses-permission or uses-permission-sdk-23 tag containing android:name="android.permission.INTERNET". In this case, it is not necessary to perform the above Tests 1 and 2, as the platform will not allow the application to perform any network communication.

    FDP_DAR_EXT.1 Encryption Of Sensitive Application Data

    FDP_DAR_EXT.1.1
    The application shall [selection: ] in non-volatile memory.
    Application Note: If "implement functionality to encrypt sensitive data as defined in the PP-Module for File Encryption" is selected, the TSF must claim conformance to a PP-Configuration that includes the File Encryption PP-Module.

    Any file that may potentially contain sensitive data (to include temporary files) shall be protected. The only exception is if the user intentionally exports the sensitive data to non-protected files. ST authors should select "protect sensitive data in accordance with FCS_STO_EXT.1" for the sensitive data that is covered by the FCS_STO_EXT.1 SFR.
    Evaluation Activities
    FDP_DAR_EXT.1
    TSS
    The evaluator shall examine the TSS to ensure that it describes the sensitive data processed by the application. The evaluator shall then ensure that the following activities cover all of the sensitive data identified in the TSS.

    If not store any sensitive data is selected, the evaluator shall inspect the TSS to ensure that it describes how sensitive data cannot be written to non-volatile memory. The evaluator shall also ensure that this is consistent with the filesystem test below.

    Guidance
    None.

    Tests
    Evaluation activities (after the identification of the sensitive data) are to be performed on all sensitive data listed that are not covered by FCS_STO_EXT.1.

    The evaluator shall inventory the filesystem locations where the application may write data. The evaluator shall run the application and attempt to store sensitive data. The evaluator shall then inspect those areas of the filesystem to note where data was stored (if any), and determine whether it has been encrypted.

    If "leverage platform-provided functionality" is selected, the evaluation activities will be performed as stated in the following requirements, which vary on a per-platform basis.

    Platforms:Android...
    The evaluator shall inspect the TSS and verify that it describes how files containing sensitive data are stored with the MODE_PRIVATE flag set.
    Platforms:Microsoft Windows...
    The Windows platform currently does not provide data-at-rest encryption services which depend upon invocation by application developers. The evaluator shall verify that the Operational User Guidance makes the need to activate platform encryption, such as BitLocker or Encrypting File System (EFS), clear to the end user.
    Platforms:Apple iOS...
    The evaluator shall inspect the TSS and ensure that it describes how the application uses the Complete Protection, Protected Unless Open, or Protected Until First User Authentication Data Protection Class for each data file stored locally.
    Platforms:Linux...
    The Linux platform currently does not provide data-at-rest encryption services which depend upon invocation by application developers. The evaluator shall verify that the Operational User Guidance makes the need to activate platform encryption clear to the end user.
    Platforms:Oracle Solaris...
    The Solaris platform currently does not provide data-at-rest encryption services which depend upon invocation by application developers. The evaluator shall verify that the Operational User Guidance makes the need to activate platform encryption clear to the end user.
    Platforms:Apple macOS...
    The macOS platform currently does not provide data-at-rest encryption services which depend upon invocation by application developers. The evaluator shall verify that the Operational User Guidance makes the need to activate platform encryption clear to the end user.

    5.1.3 Security Management (FMT)

    FMT_MEC_EXT.1 Supported Configuration Mechanism

    FMT_MEC_EXT.1.1
    The application shall[selection: invoke the mechanisms recommended by the platform vendor for storing and setting configuration options, implement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1 in the PP-Module for File Encryption]
    Application Note: Configuration options that are stored remotely are not subject to this requirement. Sensitive Data is generally not considered part of configuration options and should be stored according to FDP_DAR_EXT.1 or FCS_STO_EXT.1.

    If “implement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1 in the PP-Module for File Encryption" is selected, the TSF must claim conformance to a PP-Configuration that includes the PP-Module for File Encryption.
    Evaluation Activities
    FMT_MEC_EXT.1
    TSS
    The evaluator shall review the TSS to identify the application's configuration options (e.g. settings) and determine whether these are stored and set using the mechanisms supported by the platform or implemented by the application in accordance with the PP-Module for File Encryption. At a minimum the TSS shall list settings related to any SFRs and any settings that are mandated in the operational guidance in response to an SFR.

    Conditional: If "implement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1 in the PP-Module for File Encryption" is selected, the evaluator shall ensure that the TSS identifies those options, as well as indicates where the encrypted representation of these options is stored.

    Guidance
    None.

    Tests
    If "invoke the mechanisms recommended by the platform vendor for storing and setting configuration options" is chosen, the method of testing varies per platform as follows:
    Platforms:Android...
    The evaluator shall run the application and make security-related changes to its configuration. The evaluator shall check that at least one XML file at location /data/data/package/shared_prefs/ reflects the changes made to the configuration to verify that the application used SharedPreferences and/or PreferenceActivity classes for storing configuration data, where package is the Java package of the application.
    Platforms:Microsoft Windows...
    The evaluator shall determine and verify that Windows Universal Applications use either the Windows.Storage namespace, Windows.UI.ApplicationSettings namespace, or the IsolatedStorageSettings namespace for storing application specific settings. For .NET applications, the evaluator shall determine and verify that the application uses one of the locations listed in https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/ for storing application specific settings. For Classic Desktop applications, the evaluator shall run the application while monitoring it with the SysInternals tool ProcMon and make changes to its configuration. The evaluator shall verify that ProcMon logs show corresponding changes to the the Windows Registry or C:\ProgramData\ directory.
    Platforms:Apple iOS...
    The evaluator shall verify that the app uses the user defaults system or key-value store for storing all settings.
    Platforms:Linux...
    The evaluator shall run the application while monitoring it with the utility strace. The evaluator shall make security-related changes to its configuration. The evaluator shall verify that strace logs corresponding changes to configuration files that reside in /etc (for system-specific configuration), in the user's home directory (for user-specific configuration), or /var/lib/ (for configurations controlled by UI and not intended to be directly modified by an administrator).
    Platforms:Oracle Solaris...
    The evaluator shall run the application while monitoring it with the utility dtrace. The evaluator shall make security-related changes to its configuration. The evaluator shall verify that dtrace logs corresponding changes to configuration files that reside in /etc (for system-specific configuration) or in the user's home directory(for user-specific configuration).
    Platforms:Apple macOS...
    The evaluator shall verify that the application stores and retrieves settings using the NSUserDefaults class.
    If "implement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1 in the PP-Module for File Encryption" is selected, for all configuration options listed in the TSS as being stored and protected using encryption, the evaluator shall examine the contents of the configuration option storage (identified in the TSS) to determine that the options have been encrypted.

    FMT_CFG_EXT.1 Secure by Default Configuration

    FMT_CFG_EXT.1.1
    The application shall provide only enough functionality to set new credentials when configured with default credentials or no credentials.
    Application Note: Default credentials are credentials (e.g., passwords, keys) that are automatically (without user interaction) loaded onto the platform during application installation. Credentials that are generated during installation using requirements laid out in FCS_RBG_EXT.1 are not by definition default credentials.
    FMT_CFG_EXT.1.2
    The application shall be configured by default with file permissions which protect the application binaries and data files from modification by normal unprivileged users.
    Application Note: The precise expectations for file permissions vary per platform but the general intention is that a trust boundary protects the application and its data.
    Evaluation Activities
    FMT_CFG_EXT.1.1
    TSS
    The evaluator shall check the TSS to determine if the application requires any type of credentials and if the application installs with default credentials.

    Guidance
    None.

    Tests
    If the application uses any default credentials the evaluator shall run the following tests.
    FMT_CFG_EXT.1.2
    TSS
    None.

    Guidance
    None.

    Tests
    The evaluator shall install and run the application. The evaluator shall inspect the filesystem of the platform (to the extent possible) for any files created by the application and ensure that their permissions are adequate to protect them. The method of doing so varies per platform.
    Platforms:Android...
    The evaluator shall run the command find -L . -perm /002 inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.
    Platforms:Microsoft Windows...
    The evaluator shall run the SysInternals tools, Process Monitor and Access Check (or tools of equivalent capability, like icacls.exe) for Classic Desktop applications to verify that files written to disk during an application's installation have the correct file permissions, such that a standard user cannot modify the application or its data files. For Windows Universal Applications the evaluator shall consider the requirement met because of the AppContainer sandbox.
    Platforms:Apple iOS...
    The evaluator shall determine whether the application leverages the appropriate Data Protection Class for each data file stored locally.
    Platforms:Linux...
    The evaluator shall run the command find -L . -perm /002 inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.
    Platforms:Oracle Solaris...
    The evaluator shall run the command find . \( -perm -002 \) inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.
    Platforms:Apple macOS...
    The evaluator shall run the command find . -perm +002 inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.

    FMT_SMF.1 Specification of Management Functions

    FMT_SMF.1.1
    The TSF shall be capable of performing the following management functions [selection: ].
    Application Note: This requirement stipulates that an application needs to provide the ability to enable/disable only those functions that it actually implements. The application is not responsible for controlling the behavior of the platform or other applications.
    Evaluation Activities
    FMT_SMF.1
    TSS
    None.

    Guidance
    The evaluator shall verify that every management function mandated by the PP is described in the operational guidance and that the description contains the information required to perform the management duties associated with the management function.

    Tests
    The evaluator shall test the application's ability to provide the management functions by configuring the application and testing each option selected from above. The evaluator is expected to test these functions in all the ways in which the ST and guidance documentation state the configuration can be managed.

    5.1.4 Privacy (FPR)

    FPR_ANO_EXT.1 User Consent for Transmission of Personally Identifiable Information

    FPR_ANO_EXT.1.1
    The application shall [selection: ].
    Application Note: This requirement applies only to PII that is specifically requested by the application; it does not apply if the user volunteers PII without prompting from the application into a general (or inappropriate) data field. A dialog box that declares intent to send PII presented to the user at the time the application is started is sufficient to meet this requirement.
    Evaluation Activities
    FPR_ANO_EXT.1
    TSS
    The evaluator shall inspect the TSS documentation to identify functionality in the application where PII can be transmitted.

    Guidance
    None.

    Tests
    If require user approval before executing is selected, the evaluator shall run the application and exercise the functionality responsibly for transmitting PII and verify that user approval is required before transmission of the PII.

    5.1.5 Protection of the TSF (FPT)

    FPT_API_EXT.1 Use of Supported Services and APIs

    FPT_API_EXT.1.1
    The application shall use only documented platform APIs.
    Application Note: The definition of "documented" may vary depending upon whether the application is provided by a third party (who relies upon documented platform APIs) or by a platform vendor who may be able to guarantee support for platform APIs.
    Evaluation Activities
    FPT_API_EXT.1
    TSS
    The evaluator shall verify that the TSS lists the platform APIs used in the application.

    Guidance
    None.

    Tests
    The evaluator shall then compare the list with the supported APIs (available through e.g. developer accounts, platform developer groups) and ensure that all APIs listed in the TSS are supported.

    FPT_AEX_EXT.1 Anti-Exploitation Capabilities

    FPT_AEX_EXT.1.1
    The application shall not request to map memory at an explicit address except for [assignment: list of explicit exceptions].
    Application Note: Requesting a memory mapping at an explicit address subverts address space layout randomization (ASLR).
    FPT_AEX_EXT.1.2
    The application shall [selection: ].
    Application Note: Requesting a memory mapping with both write and execute permissions subverts the platform protection provided by DEP. If the application performs no just-in-time compiling, then the first selection must be chosen.
    FPT_AEX_EXT.1.3
    The application shall be compatible with security features provided by the platform vendor.
    Application Note: This requirement is designed to ensure that platform security features do not need to be disabled in order for the application to run.
    FPT_AEX_EXT.1.4
    The application shall not write user-modifiable files to directories that contain executable files unless explicitly directed by the user to do so.
    Application Note: The purpose of this requirement is to help ensure the integrity of application binaries by supporting file protection mechanisms such as directory-level file permissions and application whitelisting.

    A user-modifiable file for purposes of this requirement is a file that is writable by an unprivileged user of the application -- either directly through application execution or independently of the application. If the application runs in the context of the application user, then the application should not be able to write to the directory containing the application binaries -- regardless of whether the files are configuration data, audit data, or temporary files.

    Executables and user-modifiable files may not share the same parent directory, but may share directories above the parent.
    FPT_AEX_EXT.1.5
    The application shall be built with stack-based buffer overflow protection enabled.
    Evaluation Activities
    FPT_AEX_EXT.1.1
    TSS
    The evaluator shall ensure that the TSS describes the compiler flags used to enable ASLR when the application is compiled.

    Guidance
    None.

    Tests
    The evaluator shall perform either a static or dynamic analysis to determine that no memory mappings are placed at an explicit and consistent address. The method of doing so varies per platform. For those platforms requiring the same application running on two different systems, the evaluator may alternatively use the same device. After collecting the first instance of mappings, the evaluator must uninstall the application, reboot the device, and reinstall the application to collect the second instance of mappings.
    Platforms:Android...
    The evaluator shall run the same application on two different Android systems. Both devices do not need to be evaluated, as the second device is acting only as a tool. Connect via ADB and inspect /proc/PID/maps. Ensure the two different instances share no memory mappings made by the application at the same location.
    Platforms:Microsoft Windows...
    The evaluator shall run the same application on two different Windows systems and run a tool that will list all memory mapped addresses for the application. The evaluator shall then verify the two different instances share no mapping locations. The Microsoft SysInternals tool, VMMap, could be used to view memory addresses of a running application. The evaluator shall use a tool such as Microsoft's BinScope Binary Analyzer to confirm that the application has ASLR enabled.
    Platforms:Apple iOS...
    The evaluator shall perform a static analysis to search for any mmap calls (or API calls that call mmap), and ensure that no arguments are provided that request a mapping at a fixed address.
    Platforms:Linux...
    The evaluator shall run the same application on two different Linux systems. The evaluator shall then compare their memory maps using pmap -x PID to ensure the two different instances share no mapping locations.
    Platforms:Oracle Solaris...
    The evaluator shall run the same application on two different Solaris systems. The evaluator shall then compare their memory maps using pmap -x PID to ensure the two different instances share no mapping locations.
    Platforms:Apple macOS...
    The evaluator shall run the same application on two different Mac systems. The evaluator shall then compare their memory maps using vmmap PID to ensure the two different instances share no mapping locations.
    FPT_AEX_EXT.1.2
    TSS
    None.

    Guidance
    None.

    Tests
    The evaluator shall verify that no memory mapping requests are made with write and execute permissions. The method of doing so varies per platform.
    Platforms:Android...
    The evaluator shall perform static analysis on the application to verify that
    • mmap is never invoked with both the PROT_WRITE and PROT_EXEC permissions, and
    • mprotect is never invoked.
    Platforms:Microsoft Windows...
    The evaluator shall use a tool such as Microsoft's BinScope Binary Analyzer to confirm that the application passes the NXCheck. The evaluator may also ensure that the /NXCOMPAT flag was used during compilation to verify that DEP protections are enabled for the application.
    Platforms:Apple iOS...
    The evaluator shall perform static analysis on the application to verify that mprotect is never invoked with the PROT_EXEC permission.
    Platforms:Linux...
    The evaluator shall perform static analysis on the application to verify that both
    • mmap is never be invoked with both the PROT_WRITE and PROT_EXEC permissions, and
    • mprotect is never invoked with the PROT_EXEC permission.
    Platforms:Oracle Solaris...
    The evaluator shall perform static analysis on the application to verify that both
    • mmap is never be invoked with both the PROT_WRITE and PROT_EXEC permissions, and
    • mprotect is never invoked with the PROT_EXEC permission.
    Platforms:Apple macOS...
    The evaluator shall perform static analysis on the application to verify that mprotect is never invoked with the PROT_EXEC permission.
    FPT_AEX_EXT.1.3
    TSS
    None.

    Guidance
    None.

    Tests
    The evaluator shall configure the platform in the ascribed manner and carry out one of the prescribed tests:
    Platforms:Android...
    Applications running on Android cannot disable Android security features, therefore this requirement is met and no evaluation activity is required.
    Platforms:Microsoft Windows...
    If the OS platform supports Windows Defender Exploit Guard (Windows 10 version 1709 or later), then the evaluator shall ensure that the application can run successfully with Windows Defender Exploit Guard Exploit Protection configured with the following minimum mitigations enabled; Control Flow Guard (CFG), Randomize memory allocations (Bottom-Up ASLR), Export address filtering (EAF), Import address filtering (IAF), and Data Execution Prevention (DEP). The following link describes how to enable Exploit Protection, https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-exploit-guard/customize-exploit-protection.

    If the OS platform supports the Enhanced Mitigation Experience Toolkit (EMET) which can be installed on Windows 10 version 1703 and earlier, then the evaluator shall ensure that the application can run successfully with EMET configured with the following minimum mitigations enabled; Memory Protection Check, Randomize memory allocations (Bottom-Up ASLR), Export address filtering (EAF), and Data Execution Prevention (DEP).
    Platforms:Apple iOS...
    Applications running on iOS cannot disable security features, therefore this requirement is met and no evaluation activity is required.
    Platforms:Linux...
    The evaluator shall ensure that the application can successfully run on a system with either SELinux or AppArmor enabled and in enforce mode.
    Platforms:Oracle Solaris...
    The evaluator shall ensure that the application can run with Solaris Trusted Extensions enabled and enforcing.
    Platforms:Apple macOS...
    The evaluator shall ensure that the application can successfully run on macOS without disabling any security features.
    FPT_AEX_EXT.1.4
    TSS
    None.

    Guidance
    None.

    Tests
    The evaluator shall run the application and determine where it writes its files. For files where the user does not choose the destination, the evaluator shall check whether the destination directory contains executable files. This varies per platform:
    Platforms:Android...
    The evaluator shall run the program, mimicking normal usage, and note where all user-modifiable files are written. The evaluator shall ensure that there are no executable files stored under /data/data/package/ where package is the Java package of the application.
    Platforms:Microsoft Windows...
    For Windows Universal Applications the evaluator shall consider the requirement met because the platform forces applications to write all data within the application working directory (sandbox). For Windows Desktop Applications the evaluator shall run the program, mimicking normal usage, and note where all user-modifiable files are written. The evaluator shall ensure that there are no executable files stored in the same directories to which the application wrote user-modifiable files.
    Platforms:Apple iOS...
    The evaluator shall consider the requirement met because the platform forces applications to write all data within the application working directory (sandbox).
    Platforms:Linux...
    The evaluator shall run the program, mimicking normal usage, and note where all user-modifiable files are written. The evaluator shall ensure that there are no executable files stored in the same directories to which the application wrote user-modifiable files.
    Platforms:Oracle Solaris...
    The evaluator shall run the program, mimicking normal usage, and note where all user-modifiable files are written. The evaluator shall ensure that there are no executable files stored in the same directories to which the application wrote user-modifiable files.
    Platforms:Apple macOS...
    The evaluator shall run the program, mimicking normal usage, and note where all user-modifiable files are written. The evaluator shall ensure that there are no executable files stored in the same directories to which the application wrote user-modifiable files.
    FPT_AEX_EXT.1.5
    TSS
    None.

    Guidance
    None.

    Tests
    The evaluator will inspect every native executable included in the TOE to ensure that stack-based buffer overflow protection is present.
    Platforms:Microsoft Windows...
    Applications that run as Managed Code in the .NET Framework do not require these stack protections. Applications developed in Object Pascal using the Delphi IDE compiled with RangeChecking enabled comply with this element. For other code, the evaluator shall review the TSS and verify that the /GS flag was used during compilation. The evaluator shall run a tool like, BinScope, that can verify the correct usage of /GS.
    For PE , the evaluator will disassemble each and ensure the following sequence appears:

    mov rcx, QWORD PTR [rsp+(...)]
    xor rcx, (...)
    call (...)
    .
    For ELF executables, the evaluator will ensure that each contains references to the symbol __stack_chk_fail.

    Tools such as Canary Detector may help automate these activities.

    FPT_IDV_EXT.1 Software Identification and Versions

    FPT_IDV_EXT.1.1
    The application shall be versioned with [selection: SWID tags that comply with minimum requirements from ISO/IEC 19770-2:2015 , [assignment: other version information]].
    Application Note: The use of SWID tag to identify application software is a requirement for DOD IT based on DoD Instruction 8500.01 which requires the use of SCAP which includes SWID tags per the NIST standard. The PP selection of "other version information" will be removed in the next major release of this protection profile. Vendors should begin to version software with valid SWID tags.

    Valid SWID tags must contain a SoftwareIdentity element and an Entity element as defined in the ISO/IEC 19770-2:2015 standard. SWID tags must be stored with a .swidtag file extensions as defined in the ISO/IEC 19770-2:2015.
    Evaluation Activities
    FPT_IDV_EXT.1
    TSS
    If "other version information" is selected the evaluator shall verify that the TSS contains an explanation of the versioning methodology.

    Guidance
    None.

    Tests
    The evaluator shall install the application, then check for the existence of version information. If SWID tags is selected the evaluator shall check for a .swidtag file. The evaluator shall open the file and verify that is contains at least a SoftwareIdentity element and an Entity element.

    FPT_LIB_EXT.1 Use of Third Party Libraries

    FPT_LIB_EXT.1.1
    The application shall be packaged with only [assignment: list of third-party libraries].
    Application Note: The intention of this requirement is for the evaluator to discover and document whether the application is including unnecessary or unexpected third-party libraries. This includes adware libraries which could present a privacy threat, as well as ensuring documentation of such libraries in case vulnerabilities are later discovered.
    Evaluation Activities
    FPT_LIB_EXT.1
    TSS
    None.

    Guidance
    None.

    Tests
    The evaluator shall install the application and survey its installation directory for dynamic libraries. The evaluator shall verify that libraries found to be packaged with or employed by the application are limited to those in the assignment.

    FPT_TUD_EXT.1 Integrity for Installation and Update

    FPT_TUD_EXT.1.1
    The application shall [selection: provide the ability, leverage the platform] to check for updates and patches to the application software.
    Application Note: This requirement is about the ability to "check" for updates. The actual installation of any updates should be done by the platform. This requirement is intended to ensure that the application can check for updates provided by the vendor, as updates provided by another source may contain malicious code.
    FPT_TUD_EXT.1.2
    The application shall [selection: provide the ability, leverage the platform] to query the current version of the application software.
    FPT_TUD_EXT.1.3
    The application shall not download, modify, replace or update its own binary code.
    Application Note: This requirement applies to the code of the application; it does not apply to mobile code technologies that are designed for download and execution by the application.
    FPT_TUD_EXT.1.4
    Application updates shall be digitally signed such that the application platform can cryptographically verify them prior to installation.
    Application Note: The specifics of the verification of updates involves requirements on the platform (and not the application), so these are not fully specified here.
    FPT_TUD_EXT.1.5
    The application is distributed [selection: with the platform OS, as an additional software package to the platform OS].
    Application Note: Application software that is distributed as part of the platform operating system is not required to be package for installation or uninstallation. If "as an additional software package to the OS" is selected the requirements from FPT_TUD_EXT.2 must be included in the ST.
    Evaluation Activities
    FPT_TUD_EXT.1.1
    TSS
    None.

    Guidance
    The evaluator shall check to ensure the guidance includes a description of how updates are performed.

    Tests
    The evaluator shall check for an update using procedures described in either the application documentation or the platform documentation and verify that the application does not issue an error. If it is updated or if it reports that no update is available this requirement is considered to be met.

    FPT_TUD_EXT.1.2
    TSS
    None.

    Guidance
    The evaluator shall verify guidance includes a description of how to query the current version of the application.

    Tests
    The evaluator shall query the application for the current version of the software according to the operational user guidance. The evaluator shall then verify that the current version matches that of the documented and installed version.

    FPT_TUD_EXT.1.3
    TSS
    None.

    Guidance
    None.

    Tests
    The evaluator shall verify that the application's executable files are not changed by the application.
    Platforms:Apple iOS...
    The evaluator shall consider the requirement met because the platform forces applications to write all data within the application working directory (sandbox).
    For all other platforms, the evaluator shall perform the following test:
    FPT_TUD_EXT.1.4
    TSS
    The evaluator shall verify that the TSS identifies how updates to the application are signed by an authorized source. The definition of an authorized source must be contained in the TSS. The evaluator shall also ensure that the TSS (or the operational guidance) describes how candidate updates are obtained.

    Guidance
    None.

    Tests
    None.

    FPT_TUD_EXT.1.5
    TSS
    The evaluator shall verify that the TSS identifies how the application is distributed. If "with the platform" is selected the evaluated shall perform a clean installation or factory reset to confirm that TOE software is included as part of the platform OS. If "as an additional package" is selected the evaluator shall perform the tests in FPT_TUD_EXT.2.

    Guidance
    None.

    Tests
    None.

    5.1.6 Trusted Path/Channel (FTP)

    FTP_DIT_EXT.1 Protection of Data in Transit

    FTP_DIT_EXT.1.1
    The application shall [selection: ] between itself and another trusted IT product.
    Application Note: Encryption is not required for applications transmitting data that is not sensitive.

    If "encrypt all transmitted" is selected and "TLS" is selected, then evaluation of elements from either FCS_TLSC_EXT.1 or FCS_TLSS_EXT.1 is required.

    If "encrypt all transmitted" is selected, "HTTPS" is selected, and the TOE acts as a client, then FCS_HTTPS_EXT.1/Client is required.

    If "encrypt all transmitted" is selected, "HTTPS" is selected, and the TOE acts as a server, then FCS_HTTPS_EXT.1/Server is required.

    If the TOE acts as a server and if "mutual authentication" is selected in the TLS Package, then FCS_HTTPS_EXT.2 is also required.

    If "encrypt all transmitted" is selected and "DTLS" is selected, then FCS_DTLS_EXT.1 is required.

    If "encrypt all transmitted" is selected and "SSH" is selected, then the TSF shall be validated against the Functional Package for Secure Shell.

    If "encrypt all transmitted" is selected and "IPsec" is selected, then the TSF must claim conformance to a PP-Configuration that includes the VPN Client PP-Module

    If "encrypt all transmitted" is selected the corresponding FCS_COP.1 requirements will be included.

    In addition to the above, FIA_X509_EXT.1 and FIA_X509_EXT.2 are required when the following is true:
    • "encrypt all transmitted" is selected and the TOE implements a protocol that requires certificates
    • "invoke platform-provided functionality to encrypt all transmitted sensitive data" is selected and the platform implements a protocol that requires certificates
    • "invoke platform-provided functionality to encrypt all transmitted data" is selected and the platform implements a protocol that requires certificates
    Note:FIA_X509_EXT.1 and FIA_X509_EXT.2 are not applicable when the TOE acts as a HTTPS/TLS server with no mutual authentication.
    Evaluation Activities
    FTP_DIT_EXT.1
    TSS
    For platform-provided functionality, the evaluator shall verify the TSS contains the calls to the platform that TOE is leveraging to invoke the functionality.

    Guidance
    None.

    Tests
    The evaluator shall perform the following tests.
    Platforms:Android...
    If "not transmit any data" is selected, the evaluator shall ensure that the application's AndroidManifest.xml file does not contain a uses-permission or uses-permission-sdk-23 tag containing android:name="android.permission.INTERNET". In this case, it is not necessary to perform the above Tests 1, 2, or 3, as the platform will not allow the application to perform any network communication.
    Platforms:Apple iOS...
    If "encrypt all transmitted data" is selected, the evaluator shall ensure that the application's Info.plist file does not contain the NSAllowsArbitraryLoads or NSExceptionAllowsInsecureHTTPLoads keys, as these keys disable iOS's Application Transport Security feature.
    5.1.7

    FCS_CKM.1 Cryptographic Key Generation Services

    The application shall TSF shall generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm[selection:
    • generate no asymmetric cryptographic keys,
    • invoke platform-provided functionality for asymmetric key generation,
    • implement asymmetric key generationRSA schemes using cryptographic key sizes of [assignment: 2048-bit or greater ] that meet [FIPS PUB 186-4, "Digital Signature Standard (DSS)", Appendix B.3]
    • ECC schemes using: [selection:
      • "NIST curves" P-384 and [selection: P-256, P-521, no other curves] that meet the following: [FIPS PUB 186-4, "Digital Signature Standard (DSS)", Appendix B.4]
      • Curve25519 schemes that meet the following: [RFC 7748]
      ]
    • FFC schemes using: [selection: cryptographic key sizes of 2048-bit or greater that meet the following [FIPS PUB 186-4, "Digital Signature Standard (DSS)", Appendix B.1], "safe-prime" groups that meet the following: [NIST Special Publication 800-56A Revision 3, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography"]]
    ].
    Application Note: If "implement asymmetric key generation" or "invoke platform-provided functionality for asymmetric key generation" is chosen, then additional The ST author must select all key generation schemes used for key establishment and entity authentication. When key generation is used for key establishment, the schemes in FCS_CKM.1/AK elements shall be included in the ST. 2/UNLOCKED and selected cryptographic protocols must match the selection. When key generation is used for entity authentication, the public key may be associated with an X.509v3 certificate.


    If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation.


    Curve25519 can only be used for ECDH and in conjunction with FDP_DAR_EXT.2.2.
    TSS
    The evaluator shall
    inspect the application and its developer documentation to determine if the application needs asymmetric key generation services. If not, the evaluator shall verify the generate no asymmetric cryptographic keys selection is present in the ST. Otherwise, the evaluation activities shall be performed as stated in the selection-based requirements.

    Guidance
    None.

    Tests
    None.

    FCS_RBG_EXT.1 Random Bit Generation Services

    FCS_RBG_EXT.1.1
    The application shall [selection: ] for its cryptographic operations.
    Application Note: The selection "invoke platform-provided DRBG functionality" should only be chosen for direct invocations of the platform DRBG, calls to platform protocols that may then call the platform's DRBG are not directly using DRBG functionality and should select "use no DRBG functionality."

    If "implement DRBG functionality" is chosen, then additional FCS_RBG_EXT.2 elements shall be included in the ST.

    In this requirement, cryptographic operations include all cryptographic key generation/derivation/agreement, IVs (for certain modes), as well as protocol-specific random values. Cryptographic operations in this requirement refer to the other cryptographic requirements in this PP, not additional functionality that is not in scope.
    Evaluation Activities
    FCS_RBG_EXT.1
    TSS
    If "use no DRBG functionality" is selected, the evaluator shall inspect the application and its developer documentation and verify that the application needs no random bit generation services.

    If "implement DRBG functionality" is selected, the evaluator shall ensure that additional FCS_RBG_EXT.2 elements are included in the ST.

    If "invoke platform-provided DRBG functionality" is selected, the evaluator performs the following activities. The evaluator shall examine the TSS to confirm that it identifies all functions (as described by the SFRs included in the ST) that obtain random numbers from the platform RBG. The evaluator shall determine that for each of these functions, the TSS states which platform interface (API) is used to obtain the random numbers. The evaluator shall confirm that each of these interfaces corresponds to the acceptable interfaces listed for each platform below.

    It should be noted that there is no expectation that the evaluators attempt to confirm that the APIs are being used correctly for the functions identified in the TSS; the activity is to list the used APIs and then do an existence check via decompilation.

    Guidance
    None.

    Tests
    If "invoke platform-provided DRBG functionality" is selected, the following tests shall be performed:

    The evaluator shall decompile the application binary using a decompiler suitable for the application (TOE). The evaluator shall search the output of the decompiler to determine that, for each API listed in the TSS, that API appears in the output. If the representation of the API does not correspond directly to the strings in the following list, the evaluator shall provide a mapping from the decompiled text to its corresponding API, with a description of why the API text does not directly correspond to the decompiled text and justification that the decompiled text corresponds to the associated API.

    The following are the per-platform list of acceptable APIs:
    Platforms:Android...
    The evaluator shall verify that the application uses at least one of javax.crypto.KeyGenerator class or the java.security.SecureRandom class or /dev/random or /dev/urandom.
    Platforms:Microsoft Windows...
    The evaluator shall verify that rand_s, RtlGenRandom, BCryptGenRandom, or CryptGenRandom API is used for classic desktop applications. The evaluator shall verify the application uses the RNGCryptoServiceProvider class or derives a class from System.Security.Cryptography.RandomNumberGenerator API for Windows Universal Applications. It is only required that the API is called/invoked, there is no requirement that the API be used directly. In future versions of this document, CryptGenRandom may be removed as an option as it is no longer the preferred API per vendor documentation.
    Platforms:Apple iOS...
    The evaluator shall verify that the application invokes either SecRandomCopyBytes, CCRandomGenerateBytes, or CCRandomCopyBytes, or uses /dev/random directly to acquire random.
    Platforms:Linux...
    The evaluator shall verify that the application collects random from /dev/random or /dev/urandom.
    Platforms:Oracle Solaris...
    The evaluator shall verify that the application collects random from /dev/random.
    Platforms:Apple macOS...
    The evaluator shall verify that the application invokes either CCRandomGenerateBytes or CCRandomCopyBytes, or collects random from /dev/random.
    If invocation of platform-provided functionality is achieved in another way, the evaluator shall ensure the TSS describes how this is carried out, and how it is equivalent to the methods listed here (e.g. higher-level API invokes identical low-level API).

    FCS_STO_EXT.1 Storage of Credentials

    FCS_STO_EXT.1.1
    The application shall [selection: ] to non-volatile memory.
    Application Note: This requirement ensures that persistent credentials (secret keys, PKI private keys, passwords, etc) are stored securely, and never persisted in cleartext form. Application developers are encouraged to use platform mechanisms for the secure storage of credentials. Depending on the platform that may include hardware-backed protection for credential storage. Application developers must choose a selection, or multiple selections, based on all credentials that the application stores. If "not store any credentials" is selected then the application must not store any credentials. If "invoke the functionality provided by the platform to securely store" is selected then the Application developer must closely review the EA for their platform and provide documentation indicating which platform mechanisms are used to store credentials. If "implement functionality to securely store credentials" is selected, then the following components must be included in the ST: FCS_COP.1/SKC or FCS_CKM.1/PBKDF. If other cryptographic operations are used to implement the secure storage of credentials, the corresponding requirements must be included in the ST. If the OS is Linux and Java KeyStores are used to store credentials, "implement functionality to securely store credentials" must be selected.
    Evaluation Activities
    FCS_STO_EXT.1
    TSS
    The evaluator shall check the TSS to ensure that it lists all persistent credentials (secret keys, PKI private keys, or passwords) needed to meet the requirements in the ST. For each of these items, the evaluator shall confirm that the TSS lists for what purpose it is used, and how it is stored.

    Guidance
    None.

    Tests
    For all credentials for which the application implements functionality, the evaluator shall verify credentials are encrypted according to FCS_COP.1/SKC or conditioned according to FCS_CKM.1.1/AK and FCS_CKM.1/PBKDF. For all credentials for which the application invokes platform-provided functionality, the evaluator shall perform the following actions which vary per platform.
    Platforms:Android...
    The evaluator shall verify that the application uses the Android KeyStore or the Android KeyChain to store certificates.
    Platforms:Microsoft Windows...
    The evaluator shall verify that all certificates are stored in the Windows Certificate Store. The evaluator shall verify that other credentials, like passwords, are stored in the Windows Credential Manager or stored using the Data Protection API (DPAPI). For Windows Universal Applications, the evaluator shall verify that the application is using the ProtectData class and storing credentials in IsolatedStorage.
    Platforms:Apple iOS...
    The evaluator shall verify that all credentials are stored within a Keychain.
    Platforms:Linux...
    The evaluator shall verify that all keys are stored using Linux keyrings.
    Platforms:Oracle Solaris...
    The evaluator shall verify that all keys are stored using Solaris Key Management Framework (KMF).
    Platforms:Apple macOS...
    The evaluator shall verify that all credentials are stored within Keychain.

    5.1.2 User Data Protection (FDP)

    FDP_DEC_EXT.1 Access to Platform Resources

    FDP_DEC_EXT.1.1
    The application shall restrict its access to [selection: ].
    Application Note: The intent is for the evaluator to ensure that the selection captures all hardware resources which the application accesses, and that these are restricted to those which are justified. On some platforms, the application must explicitly solicit permission in order to access hardware resources. Seeking such permissions, even if the application does not later make use of the hardware resource, should still be considered access. Selections should be expressed in a manner consistent with how the application expresses its access needs to the underlying platform. For example, the platform may provide location services which implies the potential use of a variety of hardware resources (e.g. satellite receivers, WiFi, cellular radio) yet "location services" is the proper selection. This is because use of these resources can be inferred, but also because the actual usage may vary based on the particular platform. Resources that do not need to be explicitly identified are those which are ordinarily used by any application such as central processing units, main memory, displays, input devices (e.g. keyboards, mice), and persistent storage devices provided by the platform.
    FDP_DEC_EXT.1.2
    The application shall restrict its access to [selection: ].
    Application Note: "Sensitive information repositories" are defined as those collections of sensitive data that could be expected to be shared among some applications, users, or user roles, but to which not all of these would ordinarily require access.
    Evaluation Activities
    FDP_DEC_EXT.1.1
    TSS
    None.

    Guidance
    The evaluator shall perform the platform-specific actions below and inspect user documentation to determine the application's access to hardware resources. The evaluator shall ensure that this is consistent with the selections indicated. The evaluator shall review documentation provided by the application developer and for each resource which it accesses, identify the justification as to why access is required.

    Tests
    Platforms:Android...
    The evaluator shall verify that each uses-permission entry in the AndroidManifest.xml file for access to a hardware resource is reflected in the selection.
    Platforms:Microsoft Windows...
    For Windows Universal Applications the evaluator shall check the WMAppManifest.xml file for a list of required hardware capabilities. The evaluator shall verify that the user is made aware of the required hardware capabilities when the application is first installed. This includes permissions such as ID_CAP_ISV_CAMERA, ID_CAP_LOCATION, ID_CAP_NETWORKING, ID_CAP_MICROPHONE, ID_CAP_PROXIMITY and so on. A complete list of Windows App permissions can be found at: For Windows Desktop Applications the evaluator shall identify in either the application software or its documentation the list of the required hardware resources.
    Platforms:Apple iOS...
    The evaluator shall verify that either the application or the documentation provides a list of the hardware resources it accesses.
    Platforms:Linux...
    The evaluator shall verify that either the application software or its documentation provides a list of the hardware resources it accesses.
    Platforms:Oracle Solaris...
    The evaluator shall verify that either the application software or its documentation provides a list of the hardware resources it accesses.
    Platforms:Apple macOS...
    The evaluator shall verify that either the application software or its documentation provides a list of the hardware resources it accesses.
    FDP_DEC_EXT.1.2
    TSS
    None.

    Guidance
    The evaluator shall perform the platform-specific actions below and inspect user documentation to determine the application's access to sensitive information repositories. The evaluator shall ensure that this is consistent with the selections indicated. The evaluator shall review documentation provided by the application developer and for each sensitive information repository which it accesses, identify the justification as to why access is required.

    Tests
    Platforms:Android...
    The evaluator shall verify that each uses-permission entry in the AndroidManifest.xml file for access to a sensitive information repository is reflected in the selection.
    Platforms:Microsoft Windows...
    For Windows Universal Applications the evaluator shall check the WMAppManifest.xml file for a list of required capabilities. The evaluator shall identify the required information repositories when the application is first installed. This includes permissions such as ID_CAP_CONTACTS,ID_CAP_APPOINTMENTS,ID_CAP_MEDIALIB and so on. A complete list of Windows App permissions can be found at: For Windows Desktop Applications the evaluator shall identify in either the application software or its documentation the list of sensitive information repositories it accesses.
    Platforms:Apple iOS...
    The evaluator shall verify that either the application software or its documentation provides a list of the sensitive information repositories it accesses.
    Platforms:Linux...
    The evaluator shall verify that either the application software or its documentation provides a list of sensitive information repositories it accesses.
    Platforms:Oracle Solaris...
    The evaluator shall verify that either the application software or its documentation provides a list of sensitive information repositories it accesses.
    Platforms:Apple macOS...
    The evaluator shall verify that either the application software or its documentation provides a list of sensitive information repositories it accesses.

    FDP_NET_EXT.1 Network Communications

    FDP_NET_EXT.1.1
    The application shall restrict network communication to [selection: ].
    Application Note: This requirement is intended to restrict both inbound and outbound network communications to only those required, or to network communications that are user initiated. It does not apply to network communications in which the application may generically access the filesystem which may result in the platform accessing remotely mounted drives/shares.
    ensure that the TSS identifies the key sizes supported by the TOE. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme.


    Guidance
    The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key generation schemes and key sizes for all uses defined in this PP.


    Tests
    Evaluation Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.


    Key Generation for FIPS PUB 186-4 RSA Schemes


    The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d.


    Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include:
    1. Random Primes:
      • Provable primes
      • Probable primes
    2. Primes with Conditions:
      • Primes p1, p2, q1,q2, p and q shall all be provable primes
      • Primes p1, p2, q1, and q2 shall be provable primes and p and q shall be probable primes
      • Primes p1, p2, q1,q2, p and q shall all be probable primes
    To test the key generation method for the Random Provable primes method and for all the Primes with Conditions methods, the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. This includes the random seeds, the public exponent of the RSA key, and the desired key length. For each key length supported, the evaluator shall have the TSF generate 25 key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated from a known good implementation.


    If possible, the Random Probable primes method should also be verified against a known good implementation as described above. Otherwise, the evaluator shall have the TSF generate 10 keys pairs for each supported key length nlen and verify:
    • n = p*q
    • p and q are probably prime according to Miller-Rabin tests
    • GCD(p-1,e) = 1
    • GCD(q-1,e) = 1
    • 2^16 < e < 2^256 and e is an odd integer
    • |p-q| > 2^(nlen/2 – 100)
    • p >= squareroot(2)*( 2^(nlen/2 -1) )
    • q >= squareroot(2)*( 2^(nlen/2 -1) )
    • 2^(nlen/2) < d < LCM(p-1,q-1)
    • e*d = 1 mod LCM(p-1,q-1)

    Key Generation for FIPS 186-4 Elliptic Curve Cryptography (ECC)

    FIPS 186-4 ECC Key Generation Test


    For each supported NIST curve, i.e. P-256, P-384 and P-521, the evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation.


    FIPS 186-4 Public Key Verification (PKV) Test


    For each supported NIST curve, i.e. P-256, P-384 and P-521, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e. correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values.


    Key Generation for Curve25519

    The evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated as specified in RFC 7748 using an approved random bit generator (RBG) and shall be written in little-endian order (least significant byte first). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation.


    Note: Assuming the PKV function of the good implementation will (using little-endian order):
    1. Confirm the private and public keys are 32-byte values
    2. Confirm the three least significant bits of the first byte of the private key are zero
    3. Confirm the most significant bit of the last byte is zero
    4. Confirm the second most significant bit of the last byte is one
    5. Calculate the expected public key from the private key and confirm it matches the supplied public key

    The evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify 5 of the public key values so that they are incorrect, leaving five values unchanged (i.e. correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values.


    Key Generation for Finite-Field Cryptography (FFC)

    The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and public key y.

    The Parameter generation specifies 2 ways (or methods) to generate the cryptographic prime q and the field prime p:


    Cryptographic and Field Primes:


    • Primes q and p shall both be provable primes
    • Primes q and field prime p shall both be probable primes
    and two ways to generate the cryptographic group generator g:


    Cryptographic Group Generator:


    • Generator g constructed through a verifiable process
    • Generator g constructed through an unverifiable process
    The Key generation specifies 2 ways to generate the private key x:


    Private Key:


    • len(q) bit output of RBG where 1 < = x < = q-1
    • len(q) + 64 bit output of RBG, followed by a mod q-1 operation where 1 < = x < =q-1
    The security strength of the RBG must be at least that of the security offered by the FFC parameter set.


    To test the cryptographic and field prime generation method for the provable primes method or the group generator g for a verifiable process, the evaluator must seed the TSF parameter generation routine with sufficient data to deterministically generate the parameter set.


    For each key length supported, the evaluator shall have the TSF generate 25 parameter sets and key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated from a known good implementation. Verification must also confirm

    • g != 0,1
    • q divides p-1
    • g^q mod p = 1
    • g^x mod p = y

    for each FFC parameter set and key pair.


    FCS_CKM.2/LOCKED Cryptographic Key Establishment

    The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key establishment method:[selection:
    • [RSA-based key establishment schemes] that meet the following: [NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography”]
    • [Elliptic curve-based key establishment schemes] that meet the following: [selection: NIST Special Publication 800-56A Revision 3, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", RFC 7748, "Elliptic Curves for Security"]
    • [Finite field-based key establishment schemes] that meet the following: [NIST Special Publication 800-56A Revision 3, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography"]
    ]for the purposes of encrypting sensitive data received while the device is locked.
    Application Note: The RSA-based key establishment schemes are described in Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of other sections in SP 800-56B. If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation.


    The elliptic curves used for the key establishment scheme must correlate with the curves specified in FCS_CKM.1.1.


    The domain parameters used for the finite field-based key establishment scheme are specified by the key generation according to FCS_CKM.1.1.
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    The test for SP800-56A Revision 3 and SP800-56B key establishment schemes is performed in association with FCS_CKM.2/UNLOCKED.


    Curve25519 Key Establishment Schemes


    The evaluator shall verify a TOE's implementation of the key agreement scheme using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has implemented the components of the key agreement scheme according to the specification. These components include the calculation of the shared secret K and the hash of K.


    Function Test


    The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement role and hash function combination, the tester shall generate 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested.


    The evaluator shall obtain the shared secret value K, and the hash of K.


    The evaluator shall verify the correctness of the TSF’s implementation of a given scheme by using a known good implementation to calculate the shared secret value K and compare the hash generated from this value.


    Validity Test


    The Validity test verifies the ability of the TOE to recognize another party’s valid and invalid key agreement results. To conduct this test, the evaluator generates a set of 30 test vectors consisting of data sets including the evaluator’s public keys and the TOE’s public/private key pairs.


    The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value K or the hash of K. At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass).


    The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE’s results with the results using a known good implementation verifying that the TOE detects these errors.


    FCS_CKM.2/UNLOCKED Cryptographic Key Establishment

    The TSF shall perform cryptographic key establishment in accordance with a specified cryptographic key establishment method[selection:
    • [RSA-based key establishment schemes] that meet the following [selection: NIST Special Publication 800-56B, “Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography”, RSAES-PKCS1-v1_5 as specified in Section 7.2 of RFC 8017, "Public-Key Cryptography Standards (PKCS) #1:RSA Cryptography Specifications Version 2.2"]
    • [Elliptic curve-based key establishment schemes] that meet the following: [NIST Special Publication 800-56A Revision 3, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography"]
    • [Finite field-based key establishment schemes] that meet the following: [NIST Special Publication 800-56A Revision 3, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography"]
    ].
    Application Note: The ST author must select all key establishment schemes used for the selected cryptographic protocols and any RSA-based key establishment schemes that may be used to satisfy FDP_DAR or FCS_STG. Also, FCS_TLSC_EXT.1 requires ciphersuites that use RSA-based key establishment schemes.


    The RSA-based key establishment schemes are described in Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of other sections in SP 800-56B. If the TOE only acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation.


    The elliptic curves used for the key establishment scheme must correlate with the curves specified in FCS_CKM.1.1.


    The domain parameters used for the finite field-based key establishment scheme are specified by the key generation according to FCS_CKM.1.1. The finite field-based key establishment schemes that conform to NIST SP 800-56A Revision 3 correspond to the "safe-prime" groups selection in FCS_CKM.1.1.
    TSS
    The evaluator shall ensure that the supported key establishment schemes correspond to the key generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme.
    Guidance
    The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key establishment schemes.


    Tests
    Evaluation Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.


    The evaluator shall verify the implementation of the key establishment schemes supported by the TOE using the applicable tests below.


    SP800-56A Revision 3 Key Establishment Schemes

    The evaluator shall verify a TOE's implementation of SP800-56A Revision 3 key establishment schemes using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has implemented the components of the key agreement scheme according to the specifications in the Recommendation. These components include the calculation of the DLC primitives (the shared secret value Z) and the calculation of the derived keying material (DKM) via the Key Derivation Function (KDF). If key confirmation is supported, the evaluator shall also verify that the components of key confirmation have been implemented correctly, using the test procedures described below. This includes the parsing of the DKM, the generation of MACdata and the calculation of MacTag.


    Function Test


    The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement scheme-key agreement role combination, KDF type, and, if supported, key confirmation role- key confirmation type combination, the tester shall generate 10 sets of test vectors. The data set consists of one set of domain parameter values (FFC) or the NIST approved curve (ECC) per 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested.


    The evaluator shall obtain the DKM, the corresponding TOE’s public keys (static or ephemeral), the MAC tags, and any inputs used in the KDF, such as the Other Information field OI and TOE id fields.


    If the TOE does not use a KDF defined in SP 800-56A Revision 3, the evaluator shall obtain only the public keys and the hashed value of the shared secret.


    The evaluator shall verify the correctness of the TSF’s implementation of a given scheme by using a known good implementation to calculate the shared secret value, derive the keying material DKM, and compare hashes or MAC tags generated from these values.


    If key confirmation is supported, the TSF shall perform the above for each implemented approved MAC algorithm.


    Validity Test


    The Validity test verifies the ability of the TOE to recognize another party’s valid and invalid key agreement results with or without key confirmation. To conduct this test, the evaluator shall obtain a list of the supporting cryptographic functions included in the SP800-56A Revision 3 key agreement implementation to determine which errors the TOE should be able to recognize. The evaluator generates a set of 24 (FFC) or 30 (ECC) test vectors consisting of data sets including domain parameter values or NIST approved curves, the evaluator’s public keys, the TOE’s public/private key pairs, MacTag, and any inputs used in the KDF, such as the other info and TOE id fields.


    The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value Z, the DKM, the other information field OI, the data to be MACed, or the generated MacTag. If the TOE contains the full or partial (only ECC) public key validation, the evaluator will also individually inject errors in both parties’ static public keys, both parties’ ephemeral public keys and the TOE’s static private key to assure the TOE detects errors in the public key validation function or the partial key validation function (in ECC only). At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass).


    The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE’s results with the results using a known good implementation verifying that the TOE detects these errors.


    SP800-56B Key Establishment Schemes

    The evaluator shall verify that the TSS describes whether the TOE acts as a sender, a recipient, or both for RSA-based key establishment schemes.


    If the TOE acts as a sender, the following evaluation activity shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme:

    To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each combination of supported key establishment scheme and its options (with or without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTS-OAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA public key, the plaintext keying material, any additional input parameters if applicable, the MacKey and MacTag if key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform a key establishment encryption operation on the TOE with the same inputs (in cases where key confirmation is incorporated, the test shall use the MacKey from the test vector instead of the randomly generated MacKey used in normal operation) and ensure that the outputted ciphertext is equivalent to the ciphertext in the test vector.


    If the TOE acts as a receiver, the following evaluation activities shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme:

    To conduct this test the evaluator shall generate or obtain test vectors FCS_CKM.2.1/LOCKED from a known good implementation of the TOE supported schemes. For each combination of supported key establishment scheme and its options (with our without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTS-OAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA private key, the plaintext keying material (KeyData), any additional input parameters if applicable, the MacTag in cases where key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform the key establishment decryption operation on the TOE and ensure that the outputted plaintext keying material (KeyData) is equivalent to the plaintext keying material in the test vector. In cases where key confirmation is incorporated, the evaluator shall perform the key confirmation steps and ensure that the outputted MacTag is equivalent to the MacTag in the test vector.


    The evaluator shall ensure that the TSS describes how the TOE handles decryption errors. In accordance with NIST Special Publication 800-56B, the TOE must not reveal the particular error that occurred, either through the contents of any outputted or logged error message or through timing variations. If KTS-OAEP is supported, the evaluator shall create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800-56B section 7.2.2.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each. If KTS-KEM-KWS is supported, the evaluator shall create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800-56B section 7.2.3.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each.


    RSAES-PKCS1-v1_5 Key Establishment Schemes

    The evaluator shall verify the correctness of the TSF's implementation of RSAES-PKCS1-v1_5 by using a known good implementation for each protocol selected in FTP_ITC_EXT.1 that uses RSAES-PKCS1-v1_5.

    FFC Schemes using "safe-prime" groups

    The evaluator shall verify the correctness of the TSF's implementation of "safe-prime" groups by using a known good implementation for each protocol selected in FTP_ITC_EXT.1 that uses "safe-prime" groups. This test must be performed for each "safe-prime" group that each protocol uses.

    FCS_CKM_EXT.1 Cryptographic Key Support

    The TSF shall support[selection: immutable hardware, mutable hardware]REKs with a[selection: symmetric, asymmetric]key of strength[selection: 112 bits, 128 bits, 192 bits, 256 bits].
    Each REK shall be hardware-isolated from the OS on the TSF in runtime.
    Each REK shall be generated by an RBG in accordance with FCS_RBG_EXT.1.
    Application Note: Either asymmetric or symmetric keys are allowed; the ST author makes the selection appropriate for the device. Symmetric keys must be of size 128 or 256 bits in order to correspond with FCS_COP.1/ENCRYPT. Asymmetric keys may be of any strength corresponding to FCS_CKM.1.


    The raw key material of "immutable hardware" REKs is computationally processed by hardware and software cannot access the raw key material. Thus if immutable hardware is selected in FCS_CKM_EXT.1.1 it implicitly meets FCS_CKM_EXT.7. If mutable hardware is selected in FCS_CKM_EXT.1.1, FCS_CKM_EXT.7 must be included in the ST.


    The lack of a public/documented API for importing or exporting the REK, when a private/undocumented API exists, is not sufficient to meet this requirement.


    The RBG used to generate a REK may be an RBG native to the hardware key container or may be an off-device RBG. If performed by an off-device RBG, the device manufacturer must not be able to access a REK after the manufacturing process has been completed. The Evaluation Activities for these two cases differ.
    TSS
    The evaluator shall review the TSS to determine that a REK is supported by the TOE, that the TSS includes a description of the protection provided by the TOE for a REK, and that the TSS includes a description of the method of generation of a REK.


    The evaluator shall verify that the description of the protection of a REK describes how any reading, import, and export of that REK is prevented. For example, if the hardware protecting the REK is removable, the description should include how other devices are prevented from reading the REK. The evaluator shall verify that the TSS describes how encryption/decryption/derivation actions are isolated so as to prevent applications and system-level processes from reading the REK while allowing encryption/decryption/derivation by the key.


    The evaluator shall verify that the description includes how the OS is prevented from accessing the memory containing REK key material, which software is allowed access to the REK, how any other software in the execution environment is prevented from reading that key material, and what other mechanisms prevent the REK key material from being written to shared memory locations between the OS and the separate execution environment.


    If key derivation is performed using a REK, the evaluator shall ensure that the TSS description includes a description of the key derivation function and shall verify the key derivation uses an approved derivation mode and key expansion algorithm according to FCS_CKM_EXT.3.2.


    The evaluator shall verify that the generation of a REK meets the FCS_RBG_EXT.1.1 and FCS_RBG_EXT.1.2 requirements:

    • If REKs is/are generated on-device, the TSS shall include a description of the generation mechanism including what triggers a generation, how the functionality described by FCS_RBG_EXT.1 is invoked, and whether a separate instance of the RBG is used for REKs.
    • If REKs is/are generated off-device, the TSS shall include evidence that the RBG meets FCS_RBG_EXT.1. This will likely necessitate a second set of RBG documentation equivalent to the documentation provided for the RBG Evaluation Activities. In addition, the TSS shall describe the manufacturing process that prevents the device manufacturer from accessing any REKs.

    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    FCS_CKM_EXT.2 Cryptographic Key Random Generation

    All DEKs shall be[selection:
    • randomly generated
    • from the combination of a randomly generated DEK with another DEK or salt in a way that preserves the effective entropy of each factor by [selection: using an XOR operation, concatenating the keys and using a KDF (as described in SP 800-108), concatenating the keys and using a KDF (as described in SP 800-56C)]
    ]with entropy corresponding to the security strength of AES key sizes of[selection: 128, 256]bits.
    Application Note: The intent of this requirement is to ensure that the DEK cannot be recovered with less work than a full exhaust of the key space for AES. The key generation capability of the TOE uses an RBG implemented on the TOE device (FCS_RBG_EXT.1). Either 128-bit or 256-bit (or both) are allowed; the ST author makes the selection appropriate for the device. A DEK is used in addition to the KEK so that authentication factors can be changed without having to re-encrypt all of the user data on the device.


    The ST author selects all applicable DEK generation types implemented by the TOE.


    SP 800-56C specifies a two-step key derivation procedure that employs an extraction-then-expansion technique for deriving keying material from a shared secret generated during a key establishment scheme. The Randomness Extraction step as described in Section 5 of SP 800-56C is followed by Key Expansion using the key derivation functions defined in SP 800-108 (as described in Section 6 of SP 800-56C).
    TSS
    The evaluator shall ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as separate proprietary evidence rather than being included in the TSS.


    The evaluator shall also examine the key hierarchy section of the TSS to ensure that the formation of all DEKs is described and that the key sizes match that described by the ST author. The evaluator shall examine the key hierarchy section of the TSS to ensure that each DEK is generated or combined from keys of equal or greater security strength using one of the selected methods.

    • If the symmetric DEK is generated by an RBG, the evaluator shall review the TSS to determine that it describes how the functionality described by FCS_RBG_EXT.1 is invoked. The evaluator uses the description of the RBG functionality in FCS_RBG_EXT.1 or documentation available for the operational environment to determine that the key size being requested is greater than or equal to the key size and mode to be used for the encryption/decryption of the data.
    • If the DEK is formed from a combination, the evaluator shall verify that the TSS describes the method of combination and that this method is either an XOR or a KDF to justify that the effective entropy of each factor is preserved. The evaluator shall also verify that each combined value was originally generated from an Approved DRBG described in FCS_RBG_EXT.1.
    • If concatenating the keys and using a KDF (as described in SP 800-56C) is selected, the evaluator shall ensure the TSS includes a description of the randomness extraction step.
    The description must include how an approved untruncated MAC function is being used for the randomness extraction step and the evaluator must verify the TSS describes that the output length (in bits) of the MAC function is at least as large as the targeted security strength (in bits) of the parameter set employed by the key establishment scheme (see Tables 1-3 of SP 800-56C).


    The description must include how the MAC function being used for the randomness extraction step is related to the PRF used in the key expansion and verify the TSS description includes the correct MAC function:
    • If an HMAC-hash is used in the randomness extraction step, then the same HMAC-hash (with the same hash function hash) is used as the PRF in the key expansion step.
    • If an AES-CMAC (with key length 128, 192, or 256 bits) is used in the randomness extraction step, then AES-CMAC with a 128-bit key is used as the PRF in the key expansion step.
    • The description must include the lengths of the salt values being used in the randomness extraction step and the evaluator shall verify the TSS description includes correct salt lengths:
    • If an HMAC-hash is being used as the MAC, the salt length can be any value up to the maximum bit length permitted for input to the hash function hash.
    • If an AES-CMAC is being used as the MAC, the salt length shall be the same length as the AES key (i.e. 128, 192, or 256 bits).
    (conditional) If a KDF is used, the evaluator shall ensure that the TSS includes a description of the key derivation function and shall verify the key derivation uses an approved derivation mode and key expansion algorithm according to SP 800-108 or SP 800-56C.


    Guidance
    The evaluator uses the description of the RBG functionality in FCS_RBG_EXT.1 or documentation available for the operational environment to determine that the key size being generated or combined is identical to the key size and mode to be used for the encryption/decryption of the data.


    Tests
    If a KDF is used, the evaluator shall perform one or more of the following tests to verify the correctness of the key derivation function, depending on the modes that are supported. Table 2 maps the data fields to the notations used in SP 800-108 and SP 800-56C.


    Table 2: Notations used in SP 800-108 and SP 800-56C

    Data FieldsNotations SP 800-108SP 800-56CPseudorandom functionPRFPRFCounter lengthrrLength of output of PRFhhLength of derived keying materialLLLength of input valuesl lengthl lengthPseudorandom input values IK1 (key derivation key)Z (shared secret)Pseudorandom salt valuesn/asRandomness extraction MACn/aMAC


    Counter Mode Tests:


    The evaluator shall determine the following characteristics of the key derivation function:
    • One or more pseudorandom functions that are supported by the implementation (PRF).
    • One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
    • The length (in bits) of the output of the PRF (h).
    • Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
    • Up to two values of L that are NOT evenly divisible by h.
    • Location of the counter relative to fixed input data: before, after, or in the middle.
      • Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
      • Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
      • Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
    • The length (I_length) of the input values I.
    For each supported combination of I_length, MAC, salt, PRF, counter location, value of r, and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it. For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output.


    The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.


    Feedback Mode Tests:


    The evaluator shall determine the following characteristics of the key derivation function:
    • One or more pseudorandom functions that are supported by the implementation (PRF).
    • The length (in bits) of the output of the PRF (h).
    • Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
    • Up to two values of L that are NOT evenly divisible by h.
    • Whether or not zero-length IVs are supported.
    • Whether or not a counter is used, and if so:
      • One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
      • Location of the counter relative to fixed input data: before, after, or in the middle.
        • Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
        • Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
        • Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
    • The length (I_length) of the input values I.
    For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I and pseudorandom salt values. If the KDF supports zero-length IVs, five of these test vectors will be accompanied by pseudorandom IVs and the other five will use zero-length IVs. If zero-length IVs are not supported, each test vector will be accompanied by an pseudorandom IV. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it.


    For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.


    Double Pipeline Iteration Mode Tests:


    The evaluator shall determine the following characteristics of the key derivation function:
    • One or more pseudorandom functions that are supported by the implementation (PRF).
    • The length (in bits) of the output of the PRF (h).
    • Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
    • Up to two values of L that are NOT evenly divisible by h.
    • Whether or not a counter is used, and if so:
      • One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
      • Location of the counter relative to fixed input data: before, after, or in the middle.
        • Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
        • Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
        • Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
    • The length (I_length) of the input values I.
    For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it.


    For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.


    FCS_CKM_EXT.3 Cryptographic Key Generation

    The TSF shall use[selection:
    • asymmetric KEKs of [assignment: security strength greater than or equal to 112 bits ] security strength
    • symmetric KEKs of [selection: 128-bit, 256-bit] security strength corresponding to at least the security strength of the keys encrypted by the KEK
    ].
    Application Note: The ST author selects all applicable KEK types implemented by the TOE.
    The TSF shall generate all KEKs using one of the following methods:
    • Derive the KEK from a Password Authentication Factor according to FCS_COP.1.1/CONDITION and
    [selection:
    • Generate the KEK using an RBG that meets this profile (as specified in FCS_RBG_EXT.1)
    • Generate the KEK using a key generation scheme that meets this profile (as specified in FCS_CKM.1)
    • Combine the KEK from other KEKs in a way that preserves the effective entropy of each factor by [selection: using an XOR operation, concatenating the keys and using a KDF (as described in SP 800-108), concatenating the keys and using a KDF (as described in SP 800-56C), encrypting one key with another]
    ].
    Application Note: The conditioning of passwords is performed in accordance with FCS_COP.1/CONDITION.


    It is expected that key generation derived from conditioning, using an RBG or generation scheme, and through combination, will each be necessary to meet the requirements set out in this document. In particular, Figure 3 has KEKs of each type: KEK_3 is generated, KEK_1 is derived from a Password Authentication Factor, and KEK_2 is combined from two KEKs. In Figure 3, KEK_3 may either be a symmetric key generated from an RBG or an asymmetric key generated using a key generation scheme according to FCS_CKM.1.


    If combined, the ST author should describe which method of combination is used in order to justify that the effective entropy of each factor is preserved.


    SP 800-56C specifies a two-step key derivation procedure that employs an extraction-then-expansion technique for deriving keying material from a shared secret generated during a key establishment scheme. The Randomness Extraction step as described in Section 5 of SP 800-56C is followed by Key Expansion using the key derivation functions defined in SP 800-108 (as described in Section 6 of SP 800-56C).
    TSS
    The evaluator shall examine the key hierarchy section of the TSS to ensure that the formation of all KEKs are described and that the key sizes match that described by the ST author. The evaluator shall examine the key hierarchy section of the TSS to ensure that each key (DEKs, software-based key storage, and KEKs) is encrypted by keys of equal or greater security strength using one of the selected methods.


    The evaluator shall review the TSS to verify that it contains a description of the conditioning used to derive KEKs. This description must include the size and storage location of salts. This activity may be performed in combination with that for FCS_COP.1/CONDITION.


    (conditional) If the symmetric KEK is generated by an RBG, the evaluator shall review the TSS to determine that it describes how the functionality described by FCS_RBG_EXT.1 is invoked. The evaluator uses the description of the RBG functionality in FCS_RBG_EXT.1 or documentation available for the operational environment to determine that the key size being requested is greater than or equal to the key size and mode to be used for the encryption/decryption of the data.


    (conditional) If the KEK is generated according to an asymmetric key scheme, the evaluator shall review the TSS to determine that it describes how the functionality described by FCS_CKM.1 is invoked. The evaluator uses the description of the key generation functionality in FCS_CKM.1 or documentation available for the operational environment to determine that the key strength being requested is greater than or equal to 112 bits.


    (conditional) If the KEK is formed from a combination, the evaluator shall verify that the TSS describes the method of combination and that this method is either an XOR, a KDF, or encryption.


    (conditional) If a KDF is used, the evaluator shall ensure that the TSS includes a description of the key derivation function and shall verify the key derivation uses an approved derivation mode and key expansion algorithm according to SP 800-108.


    (conditional) If concatenating the keys and using a KDF (as described in SP 800-56C) is selected, the evaluator shall ensure the TSS includes a description of the randomness extraction step. The description must include
    • How an approved untruncated MAC function is being used for the randomness extraction step and the evaluator must verify the TSS describes that the output length (in bits) of the MAC function is at least as large as the targeted security strength (in bits) of the parameter set employed by the key establishment scheme (see Tables 1-3 of SP 800-56C).
    • How the MAC function being used for the randomness extraction step is related to the PRF used in the key expansion and verify the TSS description includes the correct MAC function:
      • If an HMAC-hash is used in the randomness extraction step, then the same HMAC-hash (with the same hash function hash) is used as the PRF in the key expansion step.
      • If an AES-CMAC (with key length 128, 192, or 256 bits) is used in the randomness extraction step, then AES-CMAC with a 128-bit key is used as the PRF in the key expansion step.
    • The lengths of the salt values being used in the randomness extraction step and the evaluator shall verify the TSS description includes correct salt lengths:
      • If an HMAC-hash is being used as the MAC, the salt length can be any value up to the maximum bit length permitted for input to the hash function hash.
      • If an AES-CMAC is being used as the MAC, the salt length shall be the same length as the AES key (i.e. 128, 192, or 256 bits).

    The evaluator shall also ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as separate proprietary evidence rather than being included in the TSS.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    If a KDF is used, the evaluator shall perform one or more of the following tests to verify the correctness of the key derivation function, depending on the modes that are supported. Table 3 maps the data fields to the notations used in SP 800-108 and SP 800-56C.


    Table 3: Notations used in SP 800-108 and SP 800-56C

    Data FieldsNotationsSP 800-108SP 800-56CPseudorandom functionPRFPRFCounter lengthrrLength of output of PRFhhLength of derived keying materialLLLength of input valuesI_lengthI_lengthPseudorandom input values IK (key derivation key)Z (shared secret)Pseudorandom salt valuesn/asRandomness extraction MACn/aMAC


    Counter Mode Tests:


    The evaluator shall determine the following characteristics of the key derivation function:
    • One or more pseudorandom functions that are supported by the implementation (PRF).
    • One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
    • The length (in bits) of the output of the PRF (h).
    • Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
    • Up to two values of L that are NOT evenly divisible by h.
    • Location of the counter relative to fixed input data: before, after, or in the middle.
      • Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
      • Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
      • Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
    • The length (I_length) of the input values I.

    For each supported combination of I_length, MAC, salt, PRF, counter location, value of r, and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it. For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output.


    The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.


    Feedback Mode Tests:

    The evaluator shall determine the following characteristics of the key derivation function:

    • One or more pseudorandom functions that are supported by the implementation (PRF).
    • The length (in bits) of the output of the PRF (h).
    • Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
    • Up to two values of L that are NOT evenly divisible by h.
    • Whether or not zero-length IVs are supported.
    • Whether or not a counter is used, and if so:
      • One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
      • Location of the counter relative to fixed input data: before, after, or in the middle.
        • Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
        • Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
        • Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
    • The length (I_length) of the input values I.

    For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I and pseudorandom salt values. If the KDF supports zero-length IVs, five of these test vectors will be accompanied by pseudorandom IVs and the other five will use zero-length IVs. If zero-length IVs are not supported, each test vector will be accompanied by an pseudorandom IV. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it.


    For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.


    Double Pipeline Iteration Mode Tests:

    The evaluator shall determine the following characteristics of the key derivation function:

    • One or more pseudorandom functions that are supported by the implementation (PRF).
    • The length (in bits) of the output of the PRF (h).
    • Minimum and maximum values for the length (in bits) of the derived keying material (L). These values can be equal if only one value of L is supported. These must be evenly divisible by h.
    • Up to two values of L that are NOT evenly divisible by h.
    • Whether or not a counter is used, and if so:
      • One or more of the values {8, 16, 24, 32} that equal the length of the binary representation of the counter (r).
      • Location of the counter relative to fixed input data: before, after, or in the middle.
        • Counter before fixed input data: fixed input data string length (in bytes), fixed input data string value.
        • Counter after fixed input data: fixed input data string length (in bytes), fixed input data string value.
        • Counter in the middle of fixed input data: length of data before counter (in bytes), length of data after counter (in bytes), value of string input before counter, value of string input after counter.
    • The length (I_length) of the input values I.

    For each supported combination of I_length, MAC, salt, PRF, counter location (if a counter is used), value of r (if a counter is used), and value of L, the evaluator shall generate 10 test vectors that include pseudorandom input values I, and pseudorandom salt values. If there is only one value of L that is evenly divisible by h, the evaluator shall generate 20 test vectors for it.


    For each test vector, the evaluator shall supply this data to the TOE in order to produce the keying material output. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

    FCS_CKM_EXT.4 Key Destruction

    The TSF shall destroy cryptographic keys in accordance with the specified cryptographic key destruction methods:
    • By clearing the KEK encrypting the target key
    • In accordance with the following rules
      • For volatile memory, the destruction shall be executed by a single direct overwrite [selection: consisting of a pseudorandom pattern using the TSF’s RBG, consisting of zeros].
      • For non-volatile EEPROM, the destruction shall be executed by a single direct overwrite consisting of a pseudo random pattern using the TSF’s RBG (as specified in FCS_RBG_EXT.1), followed by a read-verify.
      • For non-volatile flash memory, that is not wear-leveled, the destruction shall be executed [selection: by a single direct overwrite consisting of zeros followed by a read-verify, by a block erase that erases the reference to memory that stores data as well as the data itself ].
      • For non-volatile flash memory, that is wear-leveled, the destruction shall be executed [selection: by a single direct overwrite consisting of zeros, by a block erase].
      • For non-volatile memory other than EEPROM and flash, the destruction shall be executed by a single direct overwrite with a random pattern that is changed before each write.
    Application Note: The clearing indicated above applies to each intermediate storage area for plaintext key or cryptographic critical security parameter (i.e. any storage, such as memory buffers, that is included in the path of such data) upon the transfer of the key or cryptographic critical security parameter to another location.


    Because plaintext key material is not allowed to be written to non-volatile memory (FPT_KST_EXT.1), the second selection only applies to key material written to volatile memory.
    The TSF shall destroy all plaintext keying material and critical security parameters when no longer needed.
    Application Note: For the purposes of this requirement, plaintext keying material refers to authentication data, passwords, secret/private symmetric keys, private asymmetric keys, data used to derive keys, values derived from passwords, etc.


    Key destruction procedures are performed in accordance with FCS_CKM_EXT.4.1.


    There are multiple situations in which plaintext keying material is no longer necessary, including when the TOE is powered off, when the wipe function is performed, when trusted channels are disconnected, when keying material is no longer needed by the trusted channel per the protocol, and when transitioning to the locked state (for those values derived from the Password Authentication Factor or that key material which is protected by the password-derived or biometric-unlocked KEK according to FCS_STG_EXT.2 – see Figure 3). For keys (or key material used to derive those keys) protecting sensitive data received in the locked state, "no longer needed" includes "while in the locked state."


    Trusted channels may include TLS, HTTPS, DTLS, IPsec VPNs, Bluetooth BR/EDR, and Bluetooth LE. The plaintext keying material for these channels includes (but is not limited to) master secrets, and Security Associations (SAs).


    If REKs are processed in a separate execution environment on the same Application Processor as the OS, REK key material must be cleared from RAM immediately after use, and at least, must be wiped when the device is locked, as the REK is part of the key hierarchy protecting sensitive data.
    TSS
    The evaluator shall check to ensure the TSS lists each type of plaintext key material (DEKs, software-based key storage, KEKs, trusted channel keys, passwords, etc.) and its generation and storage location.


    The evaluator shall verify that the TSS describes when each type of key material is cleared (for example, on system power off, on wipe function, on disconnection of trusted channels, when no longer needed by the trusted channel per the protocol, when transitioning to the locked state, and possibly including immediately after use, while in the locked state, etc.).


    The evaluator shall also verify that, for each type of key, the type of clearing procedure that is performed (cryptographic erase, overwrite with zeros, overwrite with random pattern, or block erase) is listed. If different types of memory are used to store the materials to be protected, the evaluator shall check to ensure that the TSS describes the clearing procedure in terms of the memory in which the data are stored.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    • Test FCS_CKM_EXT.4.2:1: Applied to each key held as plaintext in volatile memory and subject to destruction by overwrite by the TOE (whether or not the plaintext value is subsequently encrypted for storage in volatile or non-volatile memory). In the case where the only selection made for the destruction method key was removal of power, then this test is unnecessary. The evaluator shall:

      1. Record the value of the key in the TOE subject to clearing.
      2. Cause the TOE to perform a normal cryptographic processing with the key from Step #1.
      3. Cause the TOE to clear the key.
      4. Cause the TOE to stop the execution but not exit.
      5. Cause the TOE to dump the entire memory of the TOE into a binary file.
      6. Search the content of the binary file created in Step #5 for instances of the known key value from Step #1.
      7. Break the key value from Step #1 into 3 similar sized pieces and perform a search using each piece.

      Steps 1-6 ensure that the complete key does not exist anywhere in volatile memory. If a copy is found, then the test fails.


      Step 7 ensures that partial key fragments do not remain in memory. If a fragment is found, there is a minuscule chance that it is not within the context of a key (e.g., some random bits that happen to match). If this is the case the test should be repeated with a different key in Step #1. If a fragment is found the test fails.


    • Test FCS_CKM_EXT.4.2:2: Applied to each key held in non-volatile memory and subject to destruction by overwrite by the TOE. The evaluator shall use special tools (as needed), provided by the TOE developer if necessary, to view the key storage location:

      1. Record the value of the key in the TOE subject to clearing.
      2. Cause the TOE to perform a normal cryptographic processing with the key from Step #1.
      3. Cause the TOE to clear the key.
      4. Search the non-volatile memory the key was stored in for instances of the known key value from Step #1. If a copy is found, then the test fails.
      5. Break the key value from Step #1 into 3 similar sized pieces and perform a search using each piece. If a fragment is found then the test is repeated (as described for test 1 above), and if a fragment is found in the repeated test then the test fails.


    • Test FCS_CKM_EXT.4.2:3: Applied to each key held as non-volatile memory and subject to destruction by overwrite by the TOE. The evaluator shall use special tools (as needed), provided by the TOE developer if necessary, to view the key storage location:

      1. Record the storage location of the key in the TOE subject to clearing.
      2. Cause the TOE to perform a normal cryptographic processing with the key from Step #1.
      3. Cause the TOE to clear the key.
      4. Read the storage location in Step #1 of non-volatile memory to ensure the appropriate pattern is utilized.

      The test succeeds if correct pattern is used to overwrite the key in the memory location. If the pattern is not found the test fails.

    FCS_CKM_EXT.5 TSF Wipe

    The TSF shall wipe all protected data by[selection:
    • Cryptographically erasing the encrypted DEKs or the KEKs in non-volatile memory by following the requirements in FCS_CKM_EXT.4.1
    • Overwriting all PD according to the following rules:
      • For EEPROM, the destruction shall be executed by a single direct overwrite consisting of a pseudo random pattern using the TSF’s RBG (as specified in FCS_RBG_EXT.1, followed by a read-verify.
      • For flash memory, that is not wear-leveled, the destruction shall be executed [selection: by a single direct overwrite consisting of zeros followed by a read-verify, by a block erase that erases the reference to memory that stores data as well as the data itself].
      • For flash memory, that is wear-leveled, the destruction shall be executed [selection: by a single direct overwrite consisting of zeros, by a block erase].
      • For non-volatile memory other than EEPROM and flash, the destruction shall be executed by a single direct overwrite with a random pattern that is changed before each write.
    ].
    Application Note: Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well.
    The TSF shall perform a power cycle on conclusion of the wipe procedure.
    TSS
    The evaluator shall check to ensure the TSS describes how the device is wiped, the type of clearing procedure that is performed (cryptographic erase or overwrite) and, if overwrite is performed, the overwrite procedure (overwrite with zeros, overwrite three or more times by a different alternating pattern, overwrite with random pattern, or block erase).


    If different types of memory are used to store the data to be protected, the evaluator shall check to ensure that the TSS describes the clearing procedure in terms of the memory in which the data are stored (for example, data stored on flash are cleared by overwriting once with zeros, while data stored on the internal persistent storage device are cleared by overwriting three times with a random pattern that is changed before each write).


    Guidance
    The evaluator shall verify that the AGD guidance describes how to enable encryption, if it is not enabled by default. Additionally the evaluator shall verify that the AGD guidance describes how to initiate the wipe command.


    Tests
    • Test FCS_CKM_EXT.5.2:1: The evaluator shall perform one of the following tests. The test before and after the wipe command shall be identical. This test shall be repeated for each type of memory used to store the data to be protected.


    • Test FCS_CKM_EXT.5.2:2: The evaluator shall cause the device to wipe and verify that the wipe concludes with a power cycle.

    FCS_CKM_EXT.6 Salt Generation

    The TSF shall generate all salts using an RBG that meets FCS_RBG_EXT.1.
    Application Note: This requirement refers only to salt generation. In the examples given, a salt may be used as part of the scheme/algorithm. Requirements on nonces or ephemeral keys are provided elsewhere, if needed. The list below is provided for clarity, in order to give examples of where the TSF may be generating cryptographic salts; it is not exhaustive nor is it intended to mandate implementation of all of these schemes/algorithms. Cryptographic salts are generated for various uses including:
    • RSASSA-PSS signature generation
    • DSA signature generation
    • ECDSA signature generation
    • DH static key agreement scheme
    • PBKDF
    • Key Agreement Scheme in NIST SP 800-56B
    • AES GCM
    TSS
    The evaluator shall verify that the TSS contains a description regarding the salt generation, including which algorithms on the TOE require salts. The evaluator shall confirm that the salt is generated using an RBG described in FCS_RBG_EXT.1. For PBKDF derivation of KEKs, this evaluation activity may be performed in conjunction with FCS_CKM_EXT.3.2.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    FCS_COP.1/CONDITION Cryptographic Operation

    The TSF shall perform conditioning in accordance with a specified cryptographic algorithm HMAC-[selection: SHA-256, SHA-384, SHA-512] using a salt, and [selection: PBKDF2 with [assignment: number of iterations ] iterations, [assignment: key stretching function ], no other function] and output cryptographic key sizes [selection: 128, 256] that meet the following: [selection: NIST SP 800-132, no standard].
    Application Note: The key cryptographic key sizes in the third selection should be made to correspond to the KEK key sizes selected in FCS_CKM_EXT.3.


    This password must be conditioned into a string of bits that forms the submask to be used as input into the KEK. Conditioning can be performed using one of the identified hash functions and may include a key stretching function; the method used is selected by the ST author. If selected, NIST SP 800-132 requires the use of a pseudorandom function (PRF) consisting of HMAC with an approved hash function. The ST author selects the hash function used, also includes the appropriate requirements for HMAC and the hash function.


    Appendix A of NIST SP 800-132 recommends setting the iteration count in order to increase the computation needed to derive a key from a password and, therefore, increase the workload of performing a dictionary attack.
    TSS
    The evaluator shall check that the TSS describes the method by which the password is first encoded and then fed to the SHA algorithm and verify the SHA algorithm matches the first selection.


    If a key stretching function, such as PBKDF2, is selected the settings for the algorithm (padding, blocking, etc.) shall be described. The evaluator shall verify that the TSS contains a description of how the output of the hash function or key stretching function is used to form the submask that will be input into the function and is the same length as the KEK as specified in FCS_CKM_EXT.3.


    If any manipulation of the key is performed in forming the submask that will be used to form the KEK, that process shall be described in the TSS.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component. No explicit testing of the formation of the submask from the input password is required.

    FCS_COP.1/ENCRYPT Cryptographic Operation

    The TSF shall perform [ encryption/decryption ] in accordance with a specified cryptographic algorithm: [

    • AES-CBC (as defined in FIPS PUB 197, and NIST SP 800-38A) mode
    • AES-CCMP (as defined in FIPS PUB 197, NIST SP 800-38C and IEEE 802.11-2012), and
    • [selection: AES Key Wrap (KW) (as defined in NIST SP 800-38F), AES Key Wrap with Padding (KWP) (as defined in NIST SP 800-38F), AES-GCM (as defined in NIST SP 800-38D), AES-CCM (as defined in NIST SP 800-38C), AES-XTS (as defined in NIST SP 800-38E) mode, AES-CCMP-256 (as defined in NIST SP800-38C and IEEE 802.11ac-2013), AES-GCMP-256 (as defined in NIST SP800-38D and IEEE 802.11ac-2013), no other modes]
    ] and cryptographic key sizes [ 128-bit key sizes and [selection: 256-bit key sizes, no other key sizes] ].
    Application Note: For the first selection, the ST author should choose the mode or modes in which AES operates. For the second selection, the ST author should choose the key sizes that are supported by this functionality. 128-bit CBC and CCMP are required in order to comply with the PP-Module for Wireless LAN Clients, version 1.0.


    Note that to comply with the PP-Module for Wireless LAN Clients, version 1.0, AES CCMP (which uses AES in CCM as specified in SP 800-38C) with cryptographic key size of 128 bits must be implemented. If CCM is only implemented to support CCMP for WLAN, AES-CCM does not need be selected. Optionally, AES-CCMP-256 or AES-GCMP-256 with cryptographic key size of 256 bits may be implemented.
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    • Test FCS_COP.1.1/ENCRYPT:1: AES-CBC Known Answer Tests


      There are four Known Answer Tests (KATs), described below. In all KATs, the plaintext, ciphertext, and IV values shall be 128-bit blocks. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.
    • Test FCS_COP.1.1/ENCRYPT:2: AES-CBC Multi-Block Message Test


      The evaluator shall test the encrypt functionality by encrypting an i-block message where 1 < i < = 10. The evaluator shall choose a key, an IV and plaintext message of length i blocks and encrypt the message, using the mode to be tested, with the chosen key and IV. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation.


      The evaluator shall also test the decrypt functionality for each mode by decrypting an i-block message where 1 < i < = 10. The evaluator shall choose a key, an IV and a ciphertext message of length i blocks and decrypt the message, using the mode to be tested, with the chosen key and IV. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key and IV using a known good implementation.
    • Test FCS_COP.1.1/ENCRYPT:3: AES-CBC Monte Carlo Tests


      The evaluator shall test the encrypt functionality using a set of 200 plaintext, IV, and key 3-tuples. 100 of these shall use 128 bit keys, and 100 shall use 256 bit keys. The plaintext and IV values shall be 128-bit blocks. For each 3-tuple, 1000 iterations shall be run as follows:


                                               # Input: PT, IV, Key for i = 1 to 1000: if i == 1: CT[1] =
                            AES-CBC-Encrypt(Key, IV, PT) PT = IV else: CT[i] = AES-CBC-Encrypt(Key, PT) PT
                            = CT[i-1] 
                                          

      The ciphertext computed in the 1000th iteration (i.e. CT[1000]) is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation.


      The evaluator shall test the decrypt functionality using the same test as for encrypt, exchanging CT and PT and replacing AES-CBC-Encrypt with AES-CBC-Decrypt.
    • Test FCS_COP.1.1/ENCRYPT:4: The evaluator shall test the generation-encryption and decryption-verification functionality of AES-CCM for the following input parameter and tag lengths:


      • 128 bit and 256 bit keys

      • Two payload lengths. One payload length shall be the shortest supported payload length, greater than or equal to zero bytes. The other payload length shall be the longest supported payload length, less than or equal to 32 bytes (256 bits).

      • Two or three associated data lengths. One associated data length shall be 0, if supported. One associated data length shall be the shortest supported payload length, greater than or equal to zero bytes. One associated data length shall be the longest supported payload length, less than or equal to 32 bytes (256 bits). If the implementation supports an associated data length of 216 bytes, an associated data length of 216 bytes shall be tested.

      • Nonce lengths. All supported nonce lengths between 7 and 13 bytes, inclusive, shall be tested.

      • Tag lengths. All supported tag lengths of 4, 6, 8, 10, 12, 14 and 16 bytes shall be tested.
      To test the generation-encryption functionality of AES-CCM, the evaluator shall perform the following four tests:

      To determine correctness in each of the above tests, the evaluator shall compare the ciphertext with the result of generation-encryption of the same inputs with a known good implementation.


      To test the decryption-verification functionality of AES-CCM, for EACH combination of supported associated data length, payload length, nonce length and tag length, the evaluator shall supply a key value and 15 nonce, associated data and ciphertext 3-tuples and obtain either a FAIL result or a PASS result with the decrypted payload. The evaluator shall supply 10 tuples that should FAIL and 5 that should PASS per set of 15.
    • Test FCS_COP.1.1/ENCRYPT:5: The evaluator shall test the encrypt functionality using a set of 10 key, plaintext, AAD, and IV tuples for each combination of parameter lengths above and obtain the ciphertext value and tag that results from AES-GCM authenticated encrypt. Each supported tag length shall be tested at least once per set of 10. The IV value may be supplied by the evaluator or the implementation being tested, as long as it is known.
    • Test FCS_COP.1.1/ENCRYPT:6: The evaluator shall test the decrypt functionality using a set of 10 key, ciphertext, tag, AAD, and IV 5-tuples for each combination of parameter lengths above and obtain a Pass/Fail result on authentication and the decrypted plaintext if Pass. The set shall include five tuples that Pass and five that Fail.
    • Test FCS_COP.1.1/ENCRYPT:7: The evaluator shall test the encrypt functionality of XTS-AES for each combination of the following input parameter lengths:


      • 256 bit (for AES-128) and 512 bit (for AES-256) keys

      • Three data unit (i.e. plaintext) lengths. One of the data unit lengths shall be a non-zero integer multiple of 128 bits, if supported. One of the data unit lengths shall be an integer multiple of 128 bits, if supported. The third data unit length shall be either the longest supported data unit length or 216 bits, whichever is smaller.

      using a set of 100 (key, plaintext and 128-bit random tweak value) 3-tuples and obtain the ciphertext that results from XTS-AES encrypt.


      The evaluator may supply a data unit sequence number instead of the tweak value if the implementation supports it. The data unit sequence number is a base-10 number ranging between 0 and 255 that implementations convert to a tweak value internally.
    • Test FCS_COP.1.1/ENCRYPT:8: The evaluator shall test the decrypt functionality of XTS-AES using the same test as for encrypt, replacing plaintext values with ciphertext values and XTS-AES encrypt with XTS-AES decrypt.
    • Test FCS_COP.1.1/ENCRYPT:9: The evaluator shall test the authenticated encryption functionality of AES-KW for EACH combination of the following input parameter lengths:


      • 128 and 256 bit key encryption keys (KEKs)

      • Three plaintext lengths. One of the plaintext lengths shall be two semi-blocks (128 bits). One of the plaintext lengths shall be three semi-blocks (192 bits). The third data unit length shall be the longest supported plaintext length less than or equal to 64 semi-blocks (4096 bits).
      using a set of 100 key and plaintext pairs and obtain the ciphertext that results from AES-KW authenticated encryption. To determine correctness, the evaluator shall use the AES-KW authenticated-encryption function of a known good implementation.
    • Test FCS_COP.1.1/ENCRYPT:10: The evaluator shall test the authenticated-decryption functionality of AES-KW using the same test as for authenticated-encryption, replacing plaintext values with ciphertext values and AES-KW authenticated-encryption with AES-KW authenticated-decryption.
    • Test FCS_COP.1.1/ENCRYPT:11: The evaluator shall test the authenticated-encryption functionality of AES-KWP using the same test as for AES-KW authenticated-encryption with the following change in the three plaintext lengths:
      • One plaintext length shall be one octet. One plaintext length shall be 20 octets (160 bits).

      • One plaintext length shall be the longest supported plaintext length less than or equal to 512 octets (4096 bits).
    • Test FCS_COP.1.1/ENCRYPT:12: The evaluator shall test the authenticated-decryption functionality of AES-KWP using the same test as for AES-KWP authenticated-encryption, replacing plaintext values with ciphertext values and AES-KWP authenticated-encryption with AES-KWP authenticated-decryption.

    FCS_COP.1/HASH Cryptographic Operation

    The TSF shall perform [ cryptographic hashing ] in accordance with a specified cryptographic algorithm [ SHA-1 and [selection: SHA-256, SHA-384, SHA-512, no other algorithms] ] and message digest sizes [ 160 and [selection: 256 bits, 384 bits, 512 bits, no other message digest sizes] ] that meet the following: [ FIPS Pub 180-4 ].
    Application Note: Per NIST SP 800-131A, SHA-1 for generating digital signatures is no longer allowed, and SHA-1 for verification of digital signatures is strongly discouraged as there may be risk in accepting these signatures. It is expected that vendors will implement SHA-2 algorithms in accordance with SP 800-131A.


    SHA-1 is currently required in order to comply with the PP-Module for Wireless LAN Clients, version 1.0. Vendors are strongly encouraged to implement updated protocols that support the SHA-2 family; until updated protocols are supported, this PP allows support for SHA-1 implementations in compliance with SP 800-131A.


    The intent of this requirement is to specify the hashing function. The hash selection must support the message digest size selection. The hash selection should be consistent with the overall strength of the algorithm used (for example, SHA 256 for 128-bit keys).


    The TSF hashing functions can be implemented in one of two modes. The first mode is the byte­oriented mode. In this mode the TSF only hashes messages that are an integral number of bytes in length; i.e. the length (in bits) of the message to be hashed is divisible by 8. The second mode is the bit­oriented mode. In this mode the TSF hashes messages of arbitrary length. The TSF may implement either bit-oriented or byte-oriented; both implementations are not required.
    TSS
    The evaluator shall check that the association of the hash function with other TSF cryptographic functions (for example, the digital signature verification function) is documented in the TSS. The evaluator shall check that the TSS indicates if the hashing function is implemented in bit-oriented or byte-oriented mode.


    Guidance
    The evaluator checks the AGD documents to determine that any configuration that is required to be done to configure the functionality for the required hash sizes is present.


    Tests
    • Test FCS_COP.1.1/HASH:1: Short Messages Test: Bit-oriented Mode

      The evaluators devise an input set consisting of m+1 messages, where m is the block length of the hash algorithm. The length of the messages ranges sequentially from 0 to m bits. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF.
    • Test FCS_COP.1.1/HASH:2: Short Messages Test: Byte-oriented Mode

      The evaluators devise an input set consisting of m/8+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m/8 bytes, with each message being an integral number of bytes. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF.
    • Test FCS_COP.1.1/HASH:3: Selected Long Messages Test: Bit-oriented Mode

      The evaluators devise an input set consisting of m messages, where m is the block length of the hash algorithm. The length of the ith message is 512 + 99*i, where 1 ≤ i ≤ m. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF.
    • Test FCS_COP.1.1/HASH:4: Selected Long Messages Test: Byte-oriented Mode

      The evaluators devise an input set consisting of m/8 messages, where m is the block length of the hash algorithm. The length of the ith message is 512 + 8*99*i, where 1 ≤ i ≤ m/8. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF.
    • Test FCS_COP.1.1/HASH:5: Pseudorandomly Generated Messages Test: Byte-oriented Mode

      This test is for byte­oriented implementations only. The evaluators randomly generate a seed that is n bits long, where n is the length of the message digest produced by the hash function to be tested. The evaluators then formulate a set of 100 messages and associated digests by following the algorithm provided in Figure 1 of SHAVS. The evaluators then ensure that the correct result is produced when the messages are provided to the TSF.

    FCS_COP.1/KEYHMAC Cryptographic Operation

    The TSF shall perform [ keyed-hash message authentication ] in accordance with a specified cryptographic algorithm [ HMAC-SHA-1 and [selection: HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, no other algorithms] ] and cryptographic key sizes[assignment: key size (in bits) used in HMAC] and message digest sizes 160 and [selection: 256, 384, 512, no other] bits that meet the following: [ FIPS Pub 198-1, "The Keyed-Hash Message Authentication Code", and FIPS Pub 180-4, "Secure Hash Standard" ].
    Application Note: The selection in this requirement must be consistent with the key size specified for the size of the keys used in conjunction with the keyed-hash message authentication. HMAC-SHA-1 is currently required in order to comply with the PP-Module for Wireless LAN Clients, version 1.0.
    TSS
    The evaluator shall examine the TSS to ensure that it specifies the following values used by the HMAC function: key length, hash function used, block size, and output MAC length used.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    Evaluation Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.


    For each of the supported parameter sets, the evaluator shall compose 15 sets of test data. Each set shall consist of a key and message data. The evaluator shall have the TSF generate HMAC tags for these sets of test data. The resulting MAC tags shall be compared to the result of generating HMAC tags with the same key and IV using a known good implementation.

    FCS_COP.1/SIGN Cryptographic Operation

    The TSF shall perform [ cryptographic signature services (generation and verification) ] in accordance with a specified cryptographic algorithm[selection:
    • [ RSA schemes] using cryptographic key sizes of [2048-bit or greater] that meet the following: [FIPS PUB 186-4, "Digital Signature Standard (DSS)", Section 4]
    • [ECDSA schemes] using ["NIST curves" P-384 and [selection: P-256, P-521, no other curves]] that meet the following: [FIPS PUB 186-4, "Digital Signature Standard (DSS)", Section 5]
    ].
    Application Note: The ST author should choose the algorithm implemented to perform digital signatures; if more than one algorithm is available, this requirement should be iterated to specify the functionality. For the algorithm chosen, the ST author should make the appropriate assignments/selections to specify the parameters that are implemented for that algorithm.

    FCS_HTTPS_EXT.1 HTTPS Protocol

    The TSF shall implement the HTTPS protocol that complies with RFC 2818.
    The TSF shall implement HTTPS using TLS as defined in [ the Functional Package for Transport Layer Security (TLS), version 1.1 ].
    Application Note: The Functional Package for Transport Layer Security (TLS), version 1.1 must be included in the ST, with the following selections made:
    • FCS_TLS_EXT.1:
      • TLS must be selected
      • Client must be selected
    The TSF shall notify the application and[selection: not establish the connection, request application authorization to establish the connection, no other action]if the peer certificate is deemed invalid.
    Application Note: Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280.


    If not establish the connection is selected then "with no exceptions" must be selected for FCS_TLSC_EXT.1.3 in the Functional Package for Transport Layer Security (TLS), version 1.1. If request application authorization to establish the connection is selected then "except when override is authorized" must be selected for FCS_TLSC_EXT.1.3 in the Package for Transport Layer Security. If no other action is selected either selection can be made in FCS_TLSC_EXT.1.3.


    FMT_SMF.1 Function 23 configures whether to allow or disallow the establishment of a trusted channel if the peer certificate is deemed invalid.
    Validation Guidelines:

    Rule #2

    Rule #3
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    • Test FCS_HTTPS_EXT.1.3:1: The evaluator shall attempt to establish an HTTPS connection with a webserver, observe the traffic with a packet analyzer, and verify that the connection succeeds and that the traffic is identified as TLS or HTTPS.


      Other tests are performed in conjunction with testing in the Functional Package for Transport Layer Security (TLS), version 1.1.


      Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1, and the evaluator shall perform the following test:
    • Test FCS_HTTPS_EXT.1.3:2: The evaluator shall demonstrate that using a certificate without a valid certification path results in an application notification. Using the administrative guidance, the evaluator shall then load a certificate or certificates to the Trust Anchor Database needed to validate the certificate to be used in the function, and demonstrate that the function succeeds. The evaluator then shall delete one of the certificates, and show that the application is notified of the validation failure.

    FCS_IV_EXT.1 Initialization Vector Generation

    The TSF shall generate IVs in accordance with [ : References and IV Requirements for NIST-approved Cipher Modes ].
    Application Note: lists the requirements for composition of IVs according to the NIST Special Publications for each cipher mode. The composition of IVs generated for encryption according to a cryptographic protocol is addressed by the protocol. Thus, this requirement addresses only IVs generated for key storage and data storage encryption.
    TSS
    The evaluator shall examine the key hierarchy section of the TSS to ensure that the encryption of all keys is described and the formation of the IVs for each key encrypted by the same KEK meets FCS_IV_EXT.1.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    FCS_RBG_EXT.1 Random Bit Generation

    The TSF shall perform all deterministic random bit generation services in accordance with NIST Special Publication 800-90A using[selection: Hash_DRBG (any), HMAC_DRBG (any), CTR_DRBG (AES)].
    The deterministic RBG shall be seeded by an entropy source that accumulates entropy from[selection: a software-based noise source, TSF-hardware-based noise source]with a minimum of[selection: 128 bits, 256 bits]of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate.
    The TSF shall be capable of providing output of the RBG to applications running on the TSF that request random bits.
    Application Note: SP 800-90A contains three different methods of generating random numbers; each of these, in turn, depends on underlying cryptographic primitives (hash functions/ciphers). The ST author will select the function used, and include the specific underlying cryptographic primitives used in the requirement or in the TSS. While any of the identified hash functions (SHA-224, SHA-256, SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based implementations for CTR_DRBG are allowed.


    The ST author must also ensure that any underlying functions are included in the baseline requirements for the TOE.


    Health testing of the DRBGs is performed in conjunction with the self-tests required in FPT_TST_EXT.1.1.


    For the selection in FCS_RBG_EXT.1.2, the ST author selects the appropriate number of bits of entropy that corresponds to the greatest security strength of the algorithms included in the ST. Security strength is defined in Tables 2 and 3 of NIST SP 800-57A. For example, if the implementation includes 2048-bit RSA (security strength of 112 bits), AES 128 (security strength 128 bits), and HMAC-SHA-256 (security strength 256 bits), then the ST author would select 256 bits.


    The ST author may select either software or hardware noise sources. A hardware noise source is a component that produces data that cannot be explained by a deterministic rule, due to its physical nature. In other words, a hardware based noise source generates sequences of random numbers from a physical process that cannot be predicted. For example, a sampled ring oscillator consists of an odd number of inverter gates chained into a loop, with an electrical pulse traveling from inverter to inverter around the loop. The inverters are not clocked, so the precise time required for a complete circuit around the loop varies slightly as various physical effects modify the small delay time at each inverter on the line to the next inverter. This variance results in an approximate natural frequency that contains drift and jitter over time. The output of the ring oscillator consists of the oscillating binary value sampled at a constant rate from one of the inverters – a rate that is significantly slower than the oscillator’s natural frequency.
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    The evaluator shall also confirm that the operational guidance contains appropriate instructions for configuring the RNG functionality.


    Tests
    Evaluation Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.


    The evaluator shall perform 15 trials for the RNG implementation. If the RNG is configurable, the evaluator shall perform 15 trials for each configuration.


    If the RNG has prediction resistance enabled, each trial consists of (1) instantiate DRBG, (2) generate the first block of random bits (3) generate a second block of random bits (4) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The next two are additional input and entropy input for the first call to generate. The final two are additional input and entropy input for the second call to generate. These values are randomly generated. "generate one block of random bits" means to generate random bits with number of returned bits equal to the Output Block Length (as defined in NIST SP800-90A).


    If the RNG does not have prediction resistance, each trial consists of (1) instantiate DRBG, (2) generate the first block of random bits (3) reseed, (4) generate a second block of random bits (5) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 – 14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The fifth value is additional input to the first call to generate. The sixth and seventh are additional input and entropy input to the call to reseed. The final value is additional input to the second generate call.


    The following paragraphs contain more information on some of the input values to be generated/selected by the evaluator.


    • Entropy input: the length of the entropy input value must equal the seed length.
    • Nonce: If a nonce is supported (CTR_DRBG with no Derivation Function does not use a nonce), the nonce bit length is one-half the seed length.
    • Personalization string: The length of the personalization string must be ࣘ seed length. If the implementation only supports one personalization string length, then the same length can be used for both values. If more than one string length is support, the evaluator shall use personalization strings of two different lengths. If the implementation does not use a personalization string, no value needs to be supplied.
    • Additional input: the additional input bit lengths have the same defaults and restrictions as the personalization string lengths.

    FCS_SRV_EXT.1 Cryptographic Algorithm Services

    The TSF shall provide a mechanism for applications to request the TSF to perform the following cryptographic operations: [
    • All mandatory and [selection: selected algorithms, selected algorithms with the exception of ECC over curve 25519-based algorithms] in FCS_CKM.2/LOCKED
    • The following algorithms in FCS_COP.1/ENCRYPT: AES-CBC, [selection: AES Key Wrap, AES Key Wrap with Padding, AES-GCM, AES-CCM, no other modes]
    • All selected algorithms in FCS_COP.1/SIGN
    • All mandatory and selected algorithms in FCS_COP.1/HASH
    • All mandatory and selected algorithms in FCS_COP.1/KEYHMAC
    • [selection:
      • All mandatory and [selection: selected algorithms, selected algorithms with the exception of ECC over curve 25519-based algorithms] in FCS_CKM.1
      • The selected algorithms in FCS_COP.1/CONDITION
      • No other cryptographic operations
      ]
    ].
    Application Note: For each of the listed FCS components in the bulleted list, the intent is that the TOE will make available all algorithms specified for that component in the ST. For example, if for FCS_COP.1/HASH the ST author selects SHA-256, then the TOE would have to make available an interface to perform SHA-1 (the "mandatory" portion of FCS_COP.1/HASH) and SHA-256 (the "selected" portion of FCS_COP.1/HASH).


    The exception is for FCS_COP.1/ENCRYPT. The TOE is not required to make available AES_CCMP, AES_XTS, AES_GCMP-256, or AES_CCMP_256 even though they may be implemented to perform TSF-related functions. It is acceptable for the platform to not provide AES Key Wrap (KW) and AES Key Wrap with Padding (KWP) to applications even if selected in FCS_COP.1/ENCRYPT. However, the ST author is expected to select AES-GCM or AES-CCM if it is selected in the ST for the FCS_COP.1/ENCRYPT component.
    The evaluator shall verify that the API documentation provided according to includes the security functions (cryptographic algorithms) described in these requirements.
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    The evaluator shall write, or the developer shall provide access to, an application that requests cryptographic operations by the TSF. The evaluator shall verify that the results from the operation match the expected results according to the API documentation. This application may be used to assist in verifying the cryptographic operation Evaluation Activities for the other algorithm services requirements.

    5.1.3 Class: Cryptographic Storage (FCS_STG_EXT)

    The following requirements describe how keys are protected. All keys must ultimately be protected by a REK, and may optionally be protected by the user’s authentication factor. Each key’s confidentiality and integrity must be protected. This section also describes the secure key storage services to be provided by the Mobile Device for use by applications and users, applying the same level of protection for these keys as keys internal to the OS.

    FCS_STG_EXT.1 Cryptographic Key Storage

    The TSF shall provide[selection: mutable hardware, software-based]secure key storage for asymmetric private keys and[selection: symmetric keys, persistent secrets, no other keys].
    Application Note: A hardware keystore can be exposed to the TSF through a variety of interfaces, including embedded on the motherboard, USB, microSD, and Bluetooth.


    Immutable hardware is considered outside of this requirement and will be covered elsewhere.


    If the secure key storage is implemented in software that is protected as required by FCS_STG_EXT.2, the ST author must select software-based. If software-based is selected, the ST author must select all software-based key storage in FCS_STG_EXT.2.1.


    Support for secure key storage for all symmetric keys and persistent secrets will be required in future revisions.
    Validation Guidelines:

    Rule #4
    The TSF shall be capable of importing keys or secrets into the secure key storage upon request of[selection: the user, the administrator]and[selection: applications running on the TSF, no other subjects].
    Application Note: If the ST selects only the user, the ST author must select function 9 in FMT_MOF_EXT.1.1.
    The TSF shall be capable of destroying keys or secrets in the secure key storage upon request of[selection: the user, the administrator].
    Application Note: If the ST selects the user, the ST author must select function 10 in FMT_MOF_EXT.1.1.
    The TSF shall have the capability to allow only the application that imported the key or secret the use of the key or secret. Exceptions may only be explicitly authorized by[selection: the user, the administrator, a common application developer].
    Application Note: If the ST selects the user or the administrator, the ST author must also select 34 in FMT_SMF.1.1. If the ST selects the user, the ST author must select function 34 in FMT_MOF_EXT.1.1.
    The TSF shall allow only the application that imported the key or secret to request that the key or secret be destroyed. Exceptions may only be explicitly authorized by[selection: the user, the administrator, a common application developer].
    Application Note: If the ST selects the user or the administrator, the ST author must also select function 35 in FMT_SMF.1.1. If the ST selects only the user, the ST author must select function 35 in FMT_MOF_EXT.1.1.
    Validation Guidelines:

    Rule #7

    Rule #8
    The evaluator shall verify that the API documentation provided according to includes the security functions (import, use, and destruction) described in these requirements. The API documentation shall include the method by which applications restrict access to their keys or secrets in order to meet FCS_STG_EXT.1.4.
    TSS
    The evaluator shall review the TSS to determine that the TOE implements the required secure key storage. The evaluator shall ensure that the TSS contains a description of the key storage mechanism that justifies the selection of "mutable hardware" or "software-based".


    Guidance
    The evaluator shall review the AGD guidance to determine that it describes the steps needed to import or destroy keys or secrets.


    Tests
      The evaluator shall test the functionality of each security function:
    • Test FCS_STG_EXT.1.5:1: The evaluator shall import keys or secrets of each supported type according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that generates a key or secret of each supported type and calls the import functions. The evaluator shall verify that no errors occur during import.
    • Test FCS_STG_EXT.1.5:2: The evaluator shall write, or the developer shall provide access to, an application that uses an imported key or secret:

      • For RSA, the secret shall be used to sign data.
      • For ECDSA, the secret shall be used to sign data

      In the future additional types will be required to be tested:

      • For symmetric algorithms, the secret shall be used to encrypt data.
      • For persistent secrets, the secret shall be compared to the imported secret.

      The evaluator shall repeat this test with the application-imported keys or secrets and a different application’s imported keys or secrets. The evaluator shall verify that the TOE requires approval before allowing the application to use the key or secret imported by the user or by a different application:

      • The evaluator shall deny the approvals to verify that the application is not able to use the key or secret as described.
      • The evaluator shall repeat the test, allowing the approvals to verify that the application is able to use the key or secret as described.

      If the ST author has selected "common application developer", this test is performed by either using applications from different developers or appropriately (according to API documentation) not authorizing sharing.
    • Test FCS_STG_EXT.1.5:3: The evaluator shall destroy keys or secrets of each supported type according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that destroys an imported key or secret.


      The evaluator shall repeat this test with the application-imported keys or secrets and a different application’s imported keys or secrets. The evaluator shall verify that the TOE requires approval before allowing the application to destroy the key or secret imported by the administrator or by a different application:


      • The evaluator shall deny the approvals and verify that the application is still able to use the key or secret as described.
      • The evaluator shall repeat the test, allowing the approvals and verifying that the application is no longer able to use the key or secret as described.

      If the ST author has selected "common application developer", this test is performed by either using applications from different developers or appropriately (according to API documentation) not authorizing sharing.

    FCS_STG_EXT.2 Encrypted Cryptographic Key Storage

    The TSF shall encrypt all DEKs, KEKs,[assignment: any long-term trusted channel key material]and[selection: all software-based key storage, no other keys]by KEKs that are[selection:
    • Protected by the REK with [selection: encryption by a REK, encryption by a KEK chaining from a REK, encryption by a KEK that is derived from a REK]
    • Protected by the REK and the password with [selection: encryption by a REK and the password-derived KEK, encryption by a KEK chaining to a REK and the password-derived or biometric-unlocked KEK, encryption by a KEK that is derived from a REK and the password-derived or biometric-unlocked KEK]
    ].
    Application Note: The ST author must select all software-based key storage if software-based is selected in FCS_STG_EXT.1.1. If the ST author selects mutable hardware in FCS_STG_EXT.1.1, the secure key storage is not subject to this requirement. REKs are not subject to this requirement.


    A REK and the password-derived KEK may be combined to form a combined KEK (as described in FCS_CKM_EXT.3) in order to meet this requirement.


    Software-based key storage must be protected by the password or biometric and REK.


    All keys must ultimately be protected by a REK. In particular, Figure 3 has KEKs protected according to these requirements: DEK_1 meets the "encryption by a REK and the password-derived KEK" case and would be appropriate for sensitive data, DEK_2 meets the "encryption by a KEK chaining from a REK" case and would not be appropriate for sensitive data, K_1 meets the "encryption by a REK" case and is not considered a sensitive key, and K_2 meets the "encryption by a KEK chaining to a REK and the password-derived or biometric-unlocked KEK" case and is considered a sensitive key.


    Long-term trusted channel key material includes Wi-Fi (PSKs), IPsec (PSKs and client certificates) and Bluetooth keys. These keys must not be protected by the password, as they may be necessary in the locked state. For clarity, the ST author must assign any Long-term trusted channel key material supported by the TOE . At a minimum, a TOE must support at least Wi-Fi and Bluetooth keys.
    Validation Guidelines:

    Rule #4
    DEKs, KEKs,[assignment: any long-term trusted channel key material]and[selection: all software-based key storage, no other keys]shall be encrypted using one of the following methods:[selection:
    • using a SP800-56B key establishment scheme
    • using AES in the [selection: Key Wrap (KW) mode, Key Wrap with Padding (KWP) mode, GCM, CCM, CBC mode]
    ].
    Application Note: The ST author selects which key encryption schemes are used by the TOE. This requirement refers only to KEKs as defined this PP and does not refer to those KEKs specified in other standards. The ST author must assign the same Long-term trusted channel key material assigned in FCS_STG_EXT.2.1.
    TSS
    The evaluator shall review the TSS to determine that the TSS includes key hierarchy description of the protection of each DEK for data-at-rest, of software-based key storage, of long-term trusted channel keys, and of KEK related to the protection of the DEKs, long-term trusted channel keys, and software-based key storage. This description must include a diagram illustrating the key hierarchy implemented by the TOE in order to demonstrate that the implementation meets FCS_STG_EXT.2. The description shall indicate how the functionality described by FCS_RBG_EXT.1 is invoked to generate DEKs (FCS_CKM_EXT.2), the key size (FCS_CKM_EXT.2 and FCS_CKM_EXT.3) for each key, how each KEK is formed (generated, derived, or combined according to FCS_CKM_EXT.3), the integrity protection method for each encrypted key (FCS_STG_EXT.3), and the IV generation for each key encrypted by the same KEK (FCS_IV_EXT.1). More detail for each task follows the corresponding requirement.


    The evaluator shall also ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as separate proprietary evidence rather than being included in the TSS.


    TSS
    The evaluator shall examine the key hierarchy description in the TSS section to verify that each DEK and software-stored key is encrypted according to FCS_STG_EXT.2.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    FCS_STG_EXT.3 Integrity of Encrypted Key Storage

    The TSF shall protect the integrity of any encrypted DEKs and KEKs and[selection: long-term trusted channel key material, all software-based key storage, no other keys]by[selection:
    • [selection: GCM, CCM, Key Wrap, Key Wrap with Padding] cipher mode for encryption according to FCS_STG_EXT.2
    • a hash (FCS_COP.1/HASH) of the stored key that is encrypted by a key protected by FCS_STG_EXT.2
    • a keyed hash (FCS_COP.1/KEYHMAC) using a key protected by a key protected by FCS_STG_EXT.2
    • a digital signature of the stored key using an asymmetric key protected according to FCS_STG_EXT.2
    • an immediate application of the key for decrypting the protected data followed by a successful verification of the decrypted data with previously known information
    ].
    Application Note: The ST author must assign the same Long-term trusted channel key material assigned in FCS_STG_EXT.2.1.
    The TSF shall verify the integrity of the[selection: hash, digital signature, MAC]of the stored key prior to use of the key.
    Application Note: This requirement is not applicable to derived keys that are not stored. It is not expected that a single key will be protected from corruption by multiple of these methods; however, a product may use one integrity-protection method for one type of key and a different method for other types of keys. The explicit Evaluation Activities for each of the options will be addressed in each of the requirements (FCS_COP.1.1/HASH, FCS_COP.1.1/KEYHMAC).


    Key Wrapping must be implemented per SP800-38F.
    TSS
    The evaluator shall examine the key hierarchy description in the TSS section to verify that each encrypted key is integrity protected according to one of the options in FCS_STG_EXT.3.


    The evaluator shall also ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as separate proprietary evidence rather than being included in the TSS.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    5.1.4 Class: User Data Protection (FDP)

    A subset of the User Data Protection focuses on protecting Data-At-Rest, namely FDP_DAR_EXT.1 and FDP_DAR_EXT.2. Three levels of data-at-rest protection are addressed: TSF data, Protected Data (and keys), and sensitive data. Table 4 addresses the level of protection required for each level of data-at-rest.

    Table 4: Protection of Data Levels


    Data LevelProtection RequiredTSF DataTSF data does not require confidentiality, but does require integrity protection. (FPT_TST_EXT.2/PREKERNEL)Protected DataProtected data is encrypted while powered off. (FDP_DAR_EXT.1)Sensitive DataSensitive data is encrypted while in the locked state, in addition to while powered off. (FDP_DAR_EXT.2)

    All keys, protected data, and sensitive data must ultimately be protected by the REK. Sensitive data must be protected by the password in addition to the REK. In particular, Figure 3 has KEKs protected according to these requirements: DEK_1 would be appropriate for sensitive data, DEK_2 would not be appropriate for sensitive data, K_1 is not considered a sensitive key, and K_2 is considered a sensitive key.


    These requirements include a capability for encrypting sensitive data received while in the locked state, which may be considered a separate sub-category of sensitive data. This capability may be met by a key transport scheme (RSA) by using a public key to encrypt the DEK while protecting the corresponding private key with a password-derived or biometric-unlocked KEK.


    This capability may also be met by a key agreement scheme. To do so, the device generates a device-wide sensitive data asymmetric pair (the private key of which is protected by a password-derived or biometric-unlocked KEK) and an asymmetric pair for the received sensitive data to be stored. In order to store the sensitive data, the device-wide public key and data private key are used to generate a shared secret, which can be used as a KEK or a DEK. The data private key and shared secret are cleared after the data is encrypted and the data public key stored. Thus, no key material is available in the locked state to decrypt the newly stored data. Upon unlock, the device-wide private key is decrypted and is used with each data public key to regenerate the shared secret and decrypt the stored data. Figure 4, below, illustrates this scheme.




    Figure 4: Key Agreement Scheme for Encrypting Received Sensitive Data in the Locked State


    FDP_ACF_EXT.1 Access Control for System Services

    The TSF shall provide a mechanism to restrict the system services that are accessible to an application.
    Application Note: Examples of system services to which this requirement applies include:


    • Obtain data from camera and microphone input devices
    • Obtain current device location
    • Retrieve credentials from system-wide credential store
    • Retrieve contacts list / address book
    • Retrieve stored pictures
    • Retrieve text messages
    • Retrieve emails
    • Retrieve device identifier information
    • Obtain network access
    The TSF shall provide an access control policy that prevents[selection: application, groups of applications]from accessing[selection: all, private]data stored by other[selection: application, groups of applications]. Exceptions may only be explicitly authorized for such sharing by[selection: the user, the administrator, a common application developer, no one].
    Application Note: Application groups may be designated Enterprise or Personal. Applications installed by the user default to being in the Personal application group unless otherwise designated by the administrator in function 43 of FMT_SMF.1.1. Applications installed by the administrator default to being in the Enterprise application group (this category includes applications that the user requests the administrator install, for instance by selecting the application for installation through an enterprise application catalog) unless otherwise designated by the administrator in function 43 of FMT_SMF.1.1. It is acceptable for the same application to have multiple instances installed, each in different application groups. Private data is defined as data that is accessible only by the application that wrote it. Private data is distinguished from data that an application may, by design, write to shared storage areas.


    If groups of applications is selected, FDP_ACF_EXT.2 must be included in the ST.
    TSS
    The evaluator shall ensure the TSS lists all system services available for use by an application. The evaluator shall also ensure that the TSS describes how applications interface with these system services, and means by which these system services are protected by the TSF.


    The TSS shall describe which of the following categories each system service falls in:

    1. No applications are allowed access
    2. Privileged applications are allowed access
    3. Applications are allowed access by user authorization
    4. All applications are allowed access
    Privileged applications include any applications developed by the TSF developer. The TSS shall describe how privileges are granted to third-party applications. For both types of privileged applications, the TSS shall describe how and when the privileges are verified and how the TSF prevents unprivileged applications from accessing those services.


    For any services for which the user may grant access, the evaluator shall ensure that the TSS identifies whether the user is prompted for authorization when the application is installed, or during runtime. The evaluator shall ensure that the operational user guidance contains instructions for restricting application access to system services.


    Guidance
    There are no guidance evaluation activities for this element.


    Tests
    • Test FDP_ACF_EXT.1.1:1: For each system service to which no applications are allowed access, the evaluator shall attempt to access the system service with a test application and verify that the application is not able to access that system service.
    • Test FDP_ACF_EXT.1.1:2: For each system service to which only privileged applications are allowed access, the evaluator shall attempt to access the system service with an unprivileged application and verify that the application is not able to access that system service. The evaluator shall attempt to access the system service with a privileged application and verify that the application can access the service.
    • Test FDP_ACF_EXT.1.1:3: For each system service to which the user may grant access, the evaluator shall attempt to access the system service with a test application. The evaluator shall ensure that either the system blocks such accesses or prompts for user authorization. The prompt for user authorization may occur at runtime or at installation time, and should be consistent with the behavior described in the TSS.
    • Test FDP_ACF_EXT.1.1:4: For each system service listed in the TSS that is accessible by all applications, the evaluator shall test that an application can access that system service.
    TSS
    The evaluator shall examine the TSS to verify that it describes which data sharing is permitted between applications, which data sharing is not permitted, and how disallowed sharing is prevented. It is possible to select both "applications" and "groups of applications", in which case the TSS is expected to describe the data sharing policies that would be applied in each case.


    Guidance
    There are no guidance evaluation activities for this element.


    Tests
    • Test FDP_ACF_EXT.1.2:1: The evaluator shall write, or the developer shall provide, two applications, one that saves data containing a unique string and the other, which attempts to access that data. If groups of applications is selected, the applications shall be placed into different groups. If application is selected, the evaluator shall install the two applications. If private is selected, the application shall not write to a designated shared storage area. The evaluator shall verify that the second application is unable to access the stored unique string.


      If the user is selected, the evaluator shall grant access as the user and verify that the second application is able to access the stored unique string.


      If the administrator is selected, the evaluator shall grant access as the administrator and verify that the second application is able to access the stored unique string.


      If a common application developer is selected, the evaluator shall grant access to an, application with a common application developer to the first, and verify that the application is able to access the stored unique string.

    FDP_DAR_EXT.1 Protected Data Encryption

    Encryption shall cover all protected data.
    Application Note: Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well.
    Encryption shall be performed using DEKs with AES in the[selection: XTS, CBC, GCM]mode with key size[selection: 128, 256]bits.
    Application Note: IVs must be generated in accordance with FCS_IV_EXT.1.1.
    TSS
    The evaluator shall verify that the TSS section of the ST indicates which data is protected by the DAR implementation and what data is considered TSF data. The evaluator shall ensure that this data includes all protected data.


    Guidance
    The evaluator shall review the AGD guidance to determine that the description of the configuration and use of the DAR protection does not require the user to perform any actions beyond configuration and providing the authentication credential. The evaluator shall also review the AGD guidance to determine that the configuration does not require the user to identify encryption on a per-file basis.


    Tests
    • Test FDP_DAR_EXT.1.2:1: The evaluator shall enable encryption according to the AGD guidance. The evaluator shall create user data (non-system) either by creating a file or by using an application. The evaluator shall use a tool provided by the developer to verify that this data is encrypted when the product is powered off, in conjunction with Test 1 for FIA_UAU_EXT.1.

    FDP_DAR_EXT.2 Sensitive Data Encryption

    The TSF shall provide a mechanism for applications to mark data and keys as sensitive.
    Application Note: Data and keys that have been marked as sensitive will be subject to certain restrictions (through other requirements) in both the locked and unlocked states of the Mobile Device. This mechanism allows an application to choose those data and keys under its control to be subject to those requirements.


    In the future, this PP may require that all data and key created by applications will default to the "sensitive" marking, requiring an explicit "non-sensitive" marking rather than an explicit "sensitive" marking.
    The TSF shall use an asymmetric key scheme to encrypt and store sensitive data received while the product is locked.
    Application Note: Sensitive data is encrypted according to FDP_DAR_EXT.1.2. The asymmetric key scheme must be performed in accordance with FCS_CKM.2/LOCKED.


    The intent of this requirement is to allow the device to receive sensitive data while locked and to store the received data in such a way as to prevent unauthorized parties from decrypting it while in the locked state. If only a subset of sensitive data may be received in the locked state, this subset must be described in the TSS.


    Key material must be cleared when no longer needed according to FCS_CKM_EXT.4. For keys (or key material used to derive those keys) protecting sensitive data received in the locked state, "no longer needed" includes "while in the locked state." For example, in the first key scheme, this includes the DEK protecting the received data as soon as the data is encrypted. In the second key scheme this includes the private key for the data asymmetric pair, the generated shared secret, and any generated DEKs. Of course, both schemes require that a private key of an asymmetric pair (the RSA private key and the device-wide private key, respectively) be cleared when transitioning to the locked state.
    The TSF shall encrypt any stored symmetric key and any stored private key of the asymmetric keys used for the protection of sensitive data according to [ FCS_STG_EXT.2.1 selection 2 ].
    Application Note: Symmetric keys used to encrypt sensitive data while the TSF is in the unlocked state must be encrypted with (or chain to a KEK encrypted with) the REK and password-derived or biometric-unlocked KEK. A stored private key of the asymmetric key scheme for encrypting data in the locked state must be encrypted with (or chain to a KEK encrypted with) the REK and password-derived or biometric-unlocked KEK.
    The TSF shall decrypt the sensitive data that was received while in the locked state upon transitioning to the unlocked state using the asymmetric key scheme and shall re-encrypt that sensitive data using the symmetric key scheme.
    TSS
    The evaluator shall verify that the TSS includes a description of which data stored by the TSF (such as by native applications) is treated as sensitive. This data may include all or some user or enterprise data and must be specific regarding the level of protection of email, contacts, calendar appointments, messages, and documents.


    The evaluator shall examine the TSS to determine that it describes the mechanism that is provided for applications to use to mark data and keys as sensitive. This description shall also contain information reflecting how data and keys marked in this manner are distinguished from data and keys that are not (for instance, tagging, segregation in a "special" area of memory or container, etc.).


    Guidance
    There are no guidance evaluation activities for this element.


    Tests
    The evaluator shall enable encryption of sensitive data and require user authentication according to the AGD guidance. The evaluator shall try to access and create sensitive data (as defined in the ST and either by creating a file or using an application to generate sensitive data) in order to verify that no other user interaction is required.


    TSS
    The evaluator shall review the TSS section of the ST to determine that the TSS includes a description of the process of receiving sensitive data while the device is in a locked state. The evaluator shall also verify that the description indicates if sensitive data that may be received in the locked state is treated differently than sensitive data that cannot be received in the locked state. The description shall include the key scheme for encrypting and storing the received data, which must involve an asymmetric key and must prevent the sensitive data-at-rest from being decrypted by wiping all key material used to derive or encrypt the data (as described in the application note). The introduction to this section provides two different schemes that meet the requirements, but other solutions may address this requirement.


    Guidance
    There are no guidance evaluation activities for this element.


    Tests
    The evaluator shall perform the tests in FCS_CKM_EXT.4 for all key material no longer needed while in the locked state and shall ensure that keys for the asymmetric scheme are addressed in the tests performed when transitioning to the locked state.


    TSS
    The evaluator shall verify that the key hierarchy section of the TSS required for FCS_STG_EXT.2.1 includes the symmetric encryption keys (DEKs) used to encrypt sensitive data. The evaluator shall ensure that these DEKs are encrypted by a key encrypted with (or chain to a KEK encrypted with) the REK and password-derived or biometric-unlocked KEK.


    The evaluator shall verify that the TSS section of the ST that describes the asymmetric key scheme includes the protection of any private keys of the asymmetric pairs. The evaluator shall ensure that any private keys that are not wiped and are stored by the TSF are stored encrypted by a key encrypted with (or chain to a KEK encrypted with) the REK and password-derived or biometric-unlocked KEK.


    The evaluator shall also ensure that the documentation of the product's encryption key management is detailed enough that, after reading, the product's key management hierarchy is clear and that it meets the requirements to ensure the keys are adequately protected. The evaluator shall ensure that the documentation includes both an essay and one or more diagrams. Note that this may also be documented as separate proprietary evidence rather than being included in the TSS.


    Guidance
    There are no guidance evaluation activities for this element.


    Tests
    There are no test evaluation activities for this element.


    TSS
    The evaluator shall verify that the TSS section of the ST that describes the asymmetric key scheme includes a description of the actions taken by the TSF for the purposes of DAR upon transitioning to the unlocked state. These actions shall minimally include decrypting all received data using the asymmetric key scheme and re-encrypting with the symmetric key scheme used to store data while the device is unlocked.


    Guidance
    There are no guidance evaluation activities for this element.


    Tests
    There are no test evaluation activities for this element.


    FDP_IFC_EXT.1 Subset Information Flow Control

    The TSF shall[selection: provide an interface which allows a VPN client to protect all IP traffic using IPsec, provide a VPN client which can protect all IP traffic using IPsec as defined in the PP-Module for Virtual Private Network (VPN) Clients, version 2.4]with the exception of IP traffic needed to manage the VPN connection, and[selection: [assignment: traffic needed for correct functioning of the TOE ], no other traffic], when the VPN is enabled.
    Application Note: Typically, the traffic needed to manage the VPN connection is referred to as "Control Plane" traffic; whereas, the IP traffic protected by the IPsec VPN is referred to as "Data Plane" traffic. All "Data Plane" traffic must flow through the VPN connection and the VPN must not split-tunnel. “IP traffic needed for correct functioning of the TOE” comprises traffic that would prevent the TOE from proper operation if it was either blocked by or routed through the VPN. Enabling the VPN means that the VPN client has been activated by the user. If the VPN tunnel gets interrupted, then no “Data Plane” traffic should be sent without the VPN tunnel being re-established or the user disabling the VPN client.


    If no native IPsec client is validated or third-party VPN clients may also implement the required Information Flow Control, the first option must be selected. In these cases, the TOE provides an API to third-party VPN clients that allow them to configure the TOE’s network stack to perform the required Information Flow Control.


    The ST author must select the second option if the TSF implements a native VPN client ( IPsec is selected in FTP_ITC_EXT.1.1). Thus the TSF must be validated against the PP-Module for Virtual Private Network (VPN) Clients, version 2.4 and the ST author must also include from the PP-Module for Virtual Private Network (VPN) Clients, version 2.4.


    It is optional for the VPN client to be configured to be always-on per FMT_SMF.1 Function 45. Always-on means the establishment of an IPsec trusted channel to allow any communication by the TSF.
    TSS
    The evaluator shall verify that the TSS section of the ST describes the routing of IP traffic through processes on the TSF when a VPN client is enabled. The evaluator shall ensure that the description indicates which traffic does not go through the VPN and which traffic does. The evaluator shall verify that a configuration exists for each baseband protocol in which only the traffic identified by the ST author as necessary for establishing the VPN connection (IKE traffic and perhaps HTTPS or DNS traffic) or needed for the correct functioning of the TOE is not encapsulated by the VPN protocol (IPsec). The evaluator shall verify that the TSS section describes any differences in the routing of IP traffic when using any supported baseband protocols (e.g. Wi-Fi or, LTE).


    Guidance
    The evaluator shall verify that one (or more) of the following options is addressed by the documentation:

    • The description above indicates that if a VPN client is enabled, all configurations route all Data Plane traffic through the tunnel interface established by the VPN client.
    • The AGD guidance describes how the user or administrator can configure the TSF to meet this requirement.
    • The API documentation includes a security function that allows a VPN client to specify this routing.

    Tests
    • Test FDP_IFC_EXT.1.1:1: If the ST author identifies any differences in the routing between Wi-Fi and cellular protocols, the evaluator shall repeat this test with a base station implementing one of the identified cellular protocols.


      Step 1: The evaluator shall enable a Wi-Fi configuration as described in the AGD guidance (as required by FTP_ITC_EXT.1). The evaluator shall use a packet sniffing tool between the wireless access point and an Internet-connected network. The evaluator shall turn on the sniffing tool and perform actions with the device such as navigating to websites, using provided applications, and accessing other Internet resources. The evaluator shall verify that the sniffing tool captures the traffic generated by these actions, turn off the sniffing tool, and save the session data.


      Step 2: The evaluator shall configure an IPsec VPN client that supports the routing specified in this requirement, and if necessary, configure the device to perform the routing specified as described in the AGD guidance. The evaluator shall ensure the test network is capable of sending any traffic identified as exceptions. The evaluator shall turn on the sniffing tool, establish the VPN connection, and perform the same actions with the device as performed in the first step, as well as ensuring that all exception traffic is generated. The evaluator shall verify that the sniffing tool captures traffic generated by these actions, turn off the sniffing tool, and save the session data.


      Step 3: The evaluator shall examine the traffic from both step one and step two to verify that all Data Plane traffic is encapsulated by IPsec, modulo the exceptions identified in the SFR (if applicable). For each exception listed in the SFR, the evaluator shall verify that that traffic is allowed outside of the VPN tunnel. The evaluator shall examine the Security Parameter Index (SPI) value present in the encapsulated packets captured in Step two from the TOE to the Gateway and shall verify this value is the same for all actions used to generate traffic through the VPN. Note that it is expected that the SPI value for packets from the Gateway to the TOE is different than the SPI value for packets from the TOE to the Gateway. The evaluator shall be aware that IP traffic on the cellular baseband outside of the IPsec tunnel may be emanating from the baseband processor and shall verify with the manufacturer that any identified traffic is not emanating from the application processor.


      Step 4: (Conditional: If ICMP is not listed as part of the IP traffic needed for the correct functioning of the TOE) The evaluator shall perform an ICMP echo from the TOE to the IP address of another device on the local wireless network and shall verify that no packets are sent using the sniffing tool. The evaluator shall attempt to send packets to the TOE outside the VPN tunnel (i.e. not through the VPN gateway), including from the local wireless network, and shall verify that the TOE discards them.

    FDP_STG_EXT.1 User Data Storage

    The TSF shall provide protected storage for the Trust Anchor Database.
    TSS
    The evaluator shall ensure the TSS describes the Trust Anchor Database implemented that contain certificates used to meet the requirements of this PP. This description shall contain information pertaining to how certificates are loaded into the store, and how the store is protected from unauthorized access (for example, UNIX permissions) in accordance with the permissions established in FMT_SMF.1 and FMT_MOF_EXT.1.1.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    FDP_UPC_EXT.1 Inter-TSF User Data Transfer Protection

    The TSF shall provide a means for non-TSF applications executing on the TOE to use[assignment: data transfer protocol]to provide a protected communication channel between the non-TSF application and another IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data.
    The TSF shall permit the non-TSF applications to initiate communication via the trusted channel.

    FDP_UPC_EXT.1/APPS Inter-TSF User Data Transfer Protection (Applications)

    The TSF shall provide a means for non-TSF applications executing on the TOE to use [ and [selection: mutually authenticated DTLS as defined in the Functional Package for Transport Layer Security (TLS), version 1.1, IPsec as defined in the PP-Module for Virtual Private Network (VPN) Clients, version 2.4, no other protocol] ] to provide a protected communication channel between the non-TSF application and another IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data.
    Application Note: The intent of this requirement is that one of the selected protocols is available for use by user applications running on the device for use in connecting to distant-end services that are not necessarily part of the enterprise infrastructure. It should be noted that the FTP_ITC_EXT.1 requires that all TSF communications be protected using the protocols indicated in that requirement, so the protocols required by this component ride "on top of" those listed in FTP_ITC_EXT.1.


    It should also be noted that some applications are part of the TSF, and FTP_ITC_EXT.1 requires that TSF applications be protected by at least one of the protocols in first selection in FTP_ITC_EXT.1. It is not required to have two different implementations of a protocol, or two different protocols, to satisfy both this requirement (for non-TSF apps) and FTP_ITC_EXT.1 (for TSF apps), as long as the services specified are provided.


    The ST author must list which trusted channel protocols are implemented by the Mobile Device for use by non-TSF apps.


    The TSF must be validated against requirements from the Functional Package for Transport Layer Security (TLS), version 1.1, with the following selections made:
    • FCS_TLS_EXT.1:
      • TLS is selected
      • Client is selected
    • FCS_TLSC_EXT.1.1:
      • The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.
      • Mutual authentication must be selected
    • FCS_TLSC_EXT.1.3
      • With no exceptions is selected.

    If mutually authenticated DTLS as defined in the Functional Package for Transport Layer Security (TLS), version 1.1 is selected, the TSF must be validated against requirements from the Functional Package for Transport Layer Security (TLS), version 1.1, with the following selections made:
    • FCS_TLS_EXT.1:
      • DTLS is selected
      • Client is selected
    • FCS_DTLSC_EXT.1.1:
      • The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.
      • Mutual authentication must be selected
    • FCS_DTLSC_EXT.1.3
      • With no exceptions is selected.

    If the ST author selects IPsec as defined in the PP-Module for Virtual Private Network (VPN) Clients, version 2.4, the TSF must be validated against the PP-Module for Virtual Private Network (VPN) Clients.
    The TSF shall permit the non-TSF applications to initiate communication via the trusted channel.
    The evaluator shall verify that the API documentation provided according to includes the security functions (protection channel) described in these requirements, and verify that the APIs implemented to support this requirement include the appropriate settings/parameters so that the application can both provide and obtain the information needed to assure mutual identification of the endpoints of the communication as required by this component.
    TSS
    The evaluator shall examine the TSS to determine that it describes that all protocols listed in the TSS are specified and included in the requirements in the ST.


    Guidance
    The evaluator shall confirm that the operational guidance contains instructions necessary for configuring the protocols selected for use by the applications.


    Tests
      The evaluator shall write, or the developer shall provide access to, an application that requests protected channel services by the TSF. The evaluator shall verify that the results from the protected channel match the expected results according to the API documentation. This application may be used to assist in verifying the protected channel Evaluation Activities for the protocol requirements. The evaluator shall also perform the following tests:
    • Test FDP_UPC_EXT.1.2/APPS:1: The evaluators shall ensure that the application is able to initiate communications with an external IT entity using each protocol specified in the requirement, setting up the connections as described in the operational guidance and ensuring that communication is successful.
    • Test FDP_UPC_EXT.1.2/APPS:2: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data are not sent in plaintext.

    FDP_UPC_EXT.1/BLUETOOTH Inter-TSF User Data Transfer Protection (Bluetooth)

    The TSF shall provide a means for non-TSF applications executing on the TOE to use [ and [selection: Bluetooth LE in accordance with the PP-Module for Bluetooth, version 1.0, no other protocol] ] to provide a protected communication channel between the non-TSF application and another IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data.
    Application Note: If the TOE includes Bluetooth hardware, this requirement must be included in the ST. The intent of this requirement is that Bluetooth BR/EDR and optionally Bluetooth LE is available for use by user applications running on the device for use in connecting to distant-end services that are not necessarily part of the enterprise infrastructure. The ST author must list which trusted channel protocols are implemented by the Mobile Device for use by non-TSF apps.


    The TSF must be validated against requirements from the PP-Module for Bluetooth, version 1.0. It should be noted that the FTP_ITC_EXT.1 requires that all TSF communications be protected using the protocols indicated in that requirement, so the protocols required by this component ride "on top of" those listed in FTP_ITC_EXT.1.


    The TSF shall permit the non-TSF applications to initiate communication via the trusted channel.
    The evaluator shall verify that the API documentation provided according to includes the security functions (protection channel) described in these requirements, and verify that the APIs implemented to support this requirement include the appropriate settings/parameters so that the application can both provide and obtain the information needed to assure mutual identification of the endpoints of the communication as required by this component.
    TSS
    The evaluator shall examine the TSS to determine that it describes that all protocols listed in the TSS are specified and included in the requirements in the ST.


    Guidance
    The evaluator shall confirm that the operational guidance contains instructions necessary for configuring the protocols selected for use by the applications.


    Tests
      The evaluator shall write, or the developer shall provide access to, an application that requests protected channel services by the TSF. The evaluator shall verify that the results from the protected channel match the expected results according to the API documentation. This application may be used to assist in verifying the protected channel Evaluation Activities for the protocol requirements. The evaluator shall also perform the following tests:
    • Test FDP_UPC_EXT.1.2/BLUETOOTH:1: The evaluators shall ensure that the application is able to initiate communications with an external IT entity using each protocol specified in the requirement, setting up the connections as described in the operational guidance and ensuring that communication is successful.
    • Test FDP_UPC_EXT.1.2/BLUETOOTH:2: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data are not sent in plaintext.

    5.1.5 Class: Identification and Authentication (FIA)

    FIA_AFL_EXT.1 Authentication Failure Handling

    The TSF shall consider password and[selection: biometric in accordance with the Biometric Enrollment and Verification, version 1.1, hybrid, no other mechanism]as critical authentication mechanisms.
    Application Note: A critical authentication mechanism is one in which countermeasures are triggered (i.e. wipe of the device) when the maximum number of unsuccessful authentication attempts is exceeded, rendering the other factors unavailable.


    If no additional authentication mechanisms are selected in FIA_UAU.5.1, then no other mechanism must be selected. If an additional authentication mechanism is selected in FIA_UAU.5.1, then it must only be selected in FIA_AFL_EXT.1.1 if surpassing the authentication failure threshold for biometric data causes a countermeasure to be triggered regardless of the failure status of the other authentication mechanisms.


    If the TOE implements multiple Authentication Factor interfaces (for example, a DAR decryption interface, a lock screen interface, an auxiliary boot mode interface), this component applies to all available interfaces. For example, a password is a critical authentication mechanism regardless of if it is being entered at the DAR decryption interface or at a lock screen interface.
    The TSF shall detect when a configurable positive integer within[assignment: range of acceptable values for each authentication mechanism]of[selection: unique, non-unique]unsuccessful authentication attempts occur related to last successful authentication for each authentication mechanism.
    Application Note: The positive integers is configured according to FMT_SMF.1.1 function 2.


    An unique authentication attempt is defined as any attempt to verify a password or biometric sample, in which the input is different from a previous attempt. " unique" must be selected if the authentication system increments the counter only for unique unsuccessful authentication attempts. For example, if the same incorrect password is attempted twice the authentication system increments the counter once. " non-unique" must be selected if the authentication system increments the counter for each unsuccessful authentication attempt, regardless of if the input is unique. For example, if the same incorrect password is attempted twice the authentication system increments the counter twice.


    If hybrid authentication (i.e. a combination of biometric and pin/password) is supported, a failed authentication attempt can be counted as a single attempt, even if both the biometric and pin/password were incorrect.


    If the TOE supports multiple authentication mechanisms per FIA_UAU.5.1, this component applies to all authentication mechanisms. It is acceptable for each authentication mechanism to utilize an independent counter or for multiple authentication mechanisms to utilize a shared counter. The interaction between the authentication factors in regards to the authentication counter must be in accordance with FIA_UAU.5.2.


    If the TOE implements multiple Authentication Factor interfaces (for example, a DAR decryption interface, a lock screen interface, an auxiliary boot mode interface), this component applies to all available interfaces. However, it is acceptable for each Authentication Factor interface to be configurable with a different number of unsuccessful authentication attempts.
    The TSF shall maintain the number of unsuccessful authentication attempts that have occurred upon power off.
    Application Note: The TOE may implement an Authentication Factor interface that precedes another Authentication Factor interface in the boot sequence (for example, a volume DAR decryption interface which precedes the lock screen interface) before the user can access the device. In this situation, because the user must successfully authenticate to the first interface to access the second, the number of unsuccessful authentication attempts need not be maintained for the second interface.
    When the defined number of unsuccessful authentication attempts has exceeded the maximum allowed for a given authentication mechanism, all future authentication attempts will be limited to other available authentication mechanisms, unless the given mechanism is designated as a critical authentication mechanism.
    Application Note: In accordance with FIA_AFL_EXT.1.3, this requirement also applies after the TOE is powered off and powered back on.
    When the defined number of unsuccessful authentication attempts for the last available authentication mechanism or single critical authentication mechanism has been surpassed, the TSF shall perform a wipe of all protected data.
    Application Note: Wipe is performed in accordance with FCS_CKM_EXT.5. Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well.


    If the TOE implements multiple Authentication Factor interfaces (for example, a DAR decryption interface, a lock screen interface, an auxiliary boot mode interface), this component applies to all available interfaces.
    The TSF shall increment the number of unsuccessful authentication attempts prior to notifying the user that the authentication was unsuccessful.
    Application Note: This requirement is to ensure that if power is cut to the device directly after an authentication attempt, the counter will be incremented to reflect that attempt.
    TSS
    The evaluator shall ensure that the TSS describes that a value corresponding to the number of unsuccessful authentication attempts since the last successful authentication is kept for each Authentication Factor interface. The evaluator shall ensure that this description also includes if and how this value is maintained when the TOE loses power, either through a graceful powered off or an ungraceful loss of power. The evaluator shall ensure that if the value is not maintained, the interface is after another interface in the boot sequence for which the value is maintained.


    If the TOE supports multiple authentication mechanisms, the evaluator shall ensure that this description also includes how the unsuccessful authentication attempts for each mechanism selected in FIA_UAU.5.1 is handled. The evaluator shall verify that the TSS describes if each authentication mechanism utilizes its own counter or if multiple authentication mechanisms utilize a shared counter. If multiple authentication mechanisms utilize a shared counter, the evaluator shall verify that the TSS describes this interaction.


    The evaluator shall confirm that the TSS describes how the process used to determine if the authentication attempt was successful. The evaluator shall ensure that the counter would be updated even if power to the device is cut immediately following notifying the TOE user if the authentication attempt was successful or not.


    Guidance
    The evaluator shall verify that the AGD guidance describes how the administrator configures the maximum number of unique unsuccessful authentication attempts.


    Tests
    • Test FIA_AFL_EXT.1.6:1: The evaluator shall configure the device with all authentication mechanisms selected in FIA_UAU.5.1. The evaluator shall perform the following tests for each available authentication interface:


      Test 1a: The evaluator shall configure the TOE, according to the AGD guidance, with a maximum number of unsuccessful authentication attempts. The evaluator shall enter the locked state and enter incorrect passwords until the wipe occurs. The evaluator shall verify that the number of password entries corresponds to the configured maximum and that the wipe is implemented.


      Test 1b: [conditional] If the TOE supports multiple authentication mechanisms the previous test shall be repeated using a combination of authentication mechanisms confirming that the critical authentication mechanisms will cause the device to wipe and that when the maximum number of unsuccessful authentication attempts for a non-critical authentication mechanism is exceeded, the device limits authentication attempts to other available authentication mechanisms. If multiple authentication mechanisms utilize a shared counter, then the evaluator shall verify that the maximum number of unsuccessful authentication attempts can be reached by using each individual authentication mechanism and a combination of all authentication mechanisms that share the counter.
    • Test FIA_AFL_EXT.1.6:2: The evaluator shall repeat test one, but shall power off (by removing the battery, if possible) the TOE between unsuccessful authentication attempts. The evaluator shall verify that the total number of unsuccessful authentication attempts for each authentication mechanism corresponds to the configured maximum and that the critical authentication mechanisms cause the device to wipe. Alternatively, if the number of authentication failures is not maintained for the interface under test, the evaluator shall verify that upon booting the TOE between unsuccessful authentication attempts another authentication factor interface is presented before the interface under test.

    FIA_PMG_EXT.1 Password Management

    The TSF shall support the following for the Password Authentication Factor:
    1. Passwords shall be able to be composed of any combination of [selection: upper and lower case letters, [assignment: a character set of at least 52 characters ]], numbers, and special characters: [selection: "!", "@", "#", "$", "%", "^", "&", "*", "(", ")", [assignment: other characters ]];
    2. Password length up to [assignment: an integer greater than or equal to 14] characters shall be supported.
    Application Note: While some corporate policies require passwords of 14 characters or better, the use of a REK for DAR protection and key storage protection and the anti-hammer requirement (FIA_TRT_EXT.1) addresses the threat of attackers with physical access using much smaller and less complex passwords.


    The ST author selects the character set: either the upper and lower case Basic Latin letters or another assigned character set containing at least 52 characters. The assigned character set must be well defined: either according to an international encoding standard (such as Unicode) or defined in the assignment by the ST author. The ST author also selects the special characters that are supported by the TOE; they may optionally list additional special characters supported using the assignment.
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    The evaluator shall examine the operational guidance to determine that it provides guidance to security administrators on the composition of strong passwords, and that it provides instructions on setting the minimum password length. The evaluator shall also perform the following tests. Note that one or more of these tests can be performed with a single test case.
    Tests
    • Test FIA_PMG_EXT.1.1:1: The evaluator shall compose passwords that either meet the requirements, or fail to meet the requirements, in some way. For each password, the evaluator shall verify that the TOE supports the password. While the evaluator is not required (nor is it feasible) to test all possible compositions of passwords, the evaluator shall ensure that all characters, rule characteristics, and a minimum length listed in the requirement are supported, and justify the subset of those characters chosen for testing.

    FIA_TRT_EXT.1 Authentication Throttling

    The TSF shall limit automated user authentication attempts by[selection: preventing authentication via an external port, enforcing a delay between incorrect authentication attempts]for all authentication mechanisms selected in FIA_UAU.5.1. The minimum delay shall be such that no more than 10 attempts can be attempted per 500 milliseconds.
    Application Note: The authentication throttling applies to all authentication mechanisms selected in FIA_UAU.5.1. The user authentication attempts in this requirement are attempts to guess the Authentication Factor. The developer can implement the timing of the delays in the requirements using unequal or equal timing of delays. The minimum delay specified in this requirement provides defense against brute forcing.
    TSS
    The evaluator shall verify that the TSS describes the method by which authentication attempts are not able to be automated. The evaluator shall ensure that the TSS describes either how the TSF disables authentication via external interfaces (other than the ordinary user interface) or how authentication attempts are delayed in order to slow automated entry and shall ensure that this delay totals at least 500 milliseconds over 10 attempts for all authentication mechanisms selected in FIA_UAU.5.1.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    FIA_UAU.5 Multiple Authentication Mechanisms

    The TSF shall provide password and [selection: biometric in accordance with the Biometric Enrollment and Verification, version 1.1, hybrid, no other mechanism] to support user authentication.
    Application Note: The TSF must support a Password Authentication Factor and may optionally implement a BAF. A hybrid authentication factor is where a user has to submit a combination of PIN/password and biometric sample where both have to pass and if either fails the user is not made aware of which factor failed.


    If biometric in accordance with the Biometric Enrollment and Verification, version 1.1 or hybrid is selected, then the TSF must be validated against requirements from the Biometric Enrollment and Verification, version 1.1.


    If hybrid is selected, biometric in accordance with the Biometric Enrollment and Verification, version 1.1 does not need to be selected, but should be selected if the biometric authentication can be used independent of the hybrid authentication, i.e. without having to enter a PIN/password.


    The Password Authentication Factor is configured according to FIA_PMG_EXT.1.
    The TSF shall authenticate any user's claimed identity according to the[assignment: rules describing how each authentication mechanism selected in FIA_UAU.5.1 provides authentication].
    Application Note: Rules regarding how the authentication factors interact in terms of unsuccessful authentication are covered in FIA_AFL_EXT.1.
    TSS
    The evaluator shall ensure that the TSS describes each mechanism provided to support user authentication and the rules describing how the authentication mechanisms provide authentication.


    Specifically, for all authentication mechanisms specified in FIA_UAU.5.1, the evaluator shall ensure that the TSS describes the rules as to how each authentication mechanism is used. Example rules are how the authentication mechanism authenticates the user (i.e. how does the TSF verify that the correct password or biometric sample was entered), the result of a successful authentication (i.e. is the user input used to derive or unlock a key) and which authentication mechanism can be used at which authentication factor interfaces (i.e. if there are times, for example, after a reboot, that only specific authentication mechanisms can be used). If multiple BAFs are claimed in FIA_MBV_EXT.1.1 in the Biometric Enrollment and Verification, version 1.1, the interaction between the BAFs must be described. For example, whether the multiple BAFs can be enabled at the same time.


    Guidance
    The evaluator shall verify that configuration guidance for each authentication mechanism is addressed in the AGD guidance.


    Tests
    • Test FIA_UAU.5.2:1: For each authentication mechanism selected in FIA_UAU.5.1, the evaluator shall enable that mechanism and verify that it can be used to authenticate the user at the specified authentication factor interfaces.
    • Test FIA_UAU.5.2:2: For each authentication mechanism rule, the evaluator shall ensure that the authentication mechanisms behave accordingly.

    FIA_UAU.6/CREDENTIAL Re-Authenticating (Credential Change)

    The TSF shall re-authenticate the user via the Password Authentication Factor under the conditions [ attempted change to any supported authentication mechanisms ].
    Application Note: The password authentication factor must be entered before either the password or biometric authentication factor, if selected in FIA_UAU.5.1, can be changed.
    TSS
    There are no TSS evaluation activities for this element.


    Guidance
    There are no guidance evaluation activities for this element.


    Tests
    • Test FIA_UAU.6.1/CREDENTIAL:1: The evaluator shall configure the TSF to use the Password Authentication Factor according to the AGD guidance. The evaluator shall change Password Authentication Factor according to the AGD guidance and verify that the TSF requires the entry of the Password Authentication Factor before allowing the factor to be changed.
    • Test FIA_UAU.6.1/CREDENTIAL:2: [conditional] If biometric in accordance with the Biometric Enrollment and Verification, version 1.1 is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the Biometric Enrollment and Verification, version 1.1 the evaluator shall configure the TSF to use the BAF, which includes configuring the Password Authentication Factor, according to the AGD guidance. The evaluator shall change the BAF according to the AGD guidance and verify that the TSF requires the entry of the Password Authentication Factor before allowing the BAF to be changed.
    • Test FIA_UAU.6.1/CREDENTIAL:3: [conditional] If hybrid is selected in FIA_UAU.5.1, the evaluator shall configure the TSF to use the BAF and PIN or password, which includes configuring the Password Authentication Factor, according to the AGD guidance. The evaluator shall change the BAF and PIN according to the AGD guidance and verify that the TSF requires the entry of the Password Authentication Factor before allowing the factor to be changed.

    FIA_UAU.6/LOCKED Re-Authenticating (TSF Lock)

    The TSF shall re-authenticate the user via an authentication factor defined in FIA_UAU.5.1 under the conditions TSF-initiated lock, user-initiated lock, [assignment: other conditions] .
    Application Note: Depending on the selections made in FIA_UAU.5.1, either the password (at a minimum), biometric authentication or hybrid authentication mechanisms can be used to unlock the device. TSF-initiated and user-initiated locking is described in FTA_SSL_EXT.1.
    TSS
    There are no TSS evaluation activities for this element.


    Guidance
    There are no guidance evaluation activities for this element.


    Tests

    FIA_UAU.7 Protected Authentication Feedback

    The TSF shall provide only [ obscured feedback to the device’s display ] to the user while the authentication is in progress.
    Application Note: This applies to all authentication methods specified in FIA_UAU.5.1. The TSF may briefly (1 second or less) display each character or provide an option to allow the user to unmask the password; however, the password must be obscured by default.


    If biometric in accordance with the Biometric Enrollment and Verification, version 1.1 is selected in FIA_UAU.5.1, the TSF must not display sensitive information regarding any BAF that could aid an adversary in identifying or spoofing the respective biometric characteristics of a given human user. While it is true that biometric samples, by themselves, are not secret, the analysis performed by the respective biometric algorithms, as well as output data from these biometric algorithms, is considered sensitive and must be kept secret. Where applicable, the TSF must not reveal or make public the reasons for authentication failure.
    TSS
    The evaluator shall ensure that the TSS describes the means of obscuring the authentication entry, for all authentication methods specified in FIA_UAU.5.1.


    Guidance
    The evaluator shall verify that any configuration of this requirement is addressed in the AGD guidance and that the password is obscured by default.
    Tests
    • Test FIA_UAU.7.1:1: The evaluator shall enter passwords on the device, including at least the Password Authentication Factor at lock screen, and verify that the password is not displayed on the device.
    • Test FIA_UAU.7.1:2: [conditional] If biometric in accordance with the Biometric Enrollment and Verification, version 1.1 is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the Biometric Enrollment and Verification, version 1.1 the evaluator shall authenticate by producing a biometric sample at lock screen. As the biometric algorithms are performed, the evaluator shall verify that sensitive images, audio, or other information identifying the user are kept secret and are not revealed to the user. Additionally, the evaluator shall produce a biometric sample that fails to authenticate and verify that the reasons for authentication failure (user mismatch, low sample quality, etc.) are not revealed to the user. It is acceptable for the BAF to state that it was unable to physically read the biometric sample, for example, if the sensor is unclean or the biometric sample was removed too quickly. However, specifics regarding why the presented biometric sample failed authentication shall not be revealed to the user.

    FIA_UAU_EXT.1 Authentication for Cryptographic Operation

    The TSF shall require the user to present the Password Authentication Factor prior to decryption of protected data and encrypted DEKs, KEKs and[selection: long-term trusted channel key material, all software-based key storage, no other keys]at startup.
    Application Note: The intent of this requirement is to prevent decryption of protected data before the user has authorized to the device using the Password Authentication Factor. The Password Authentication Factor is also required in order derive the key used to decrypt sensitive data, which includes software-based secure key storage.
    TSS
    The evaluator shall verify that the TSS section of the ST describes the process for decrypting protected data and keys. The evaluator shall ensure that this process requires the user to enter a Password Authentication Factor and, in accordance with FCS_CKM_EXT.3, derives a KEK, which is used to protect the software-based secure key storage and (optionally) DEKs for sensitive data, in accordance with FCS_STG_EXT.2.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    • Test FIA_UAU_EXT.1.1:1: The evaluator shall enable encryption of protected data and require user authentication according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that includes a unique string treated as protected data.


      The evaluator shall reboot the device, use a tool provided by developer to search for the unique string within the application data, and verify that the unique string cannot be found. The evaluator shall enter the Password Authentication Factor to access full device functionality, use a tool provided by the developer to access the unique string within the application data, and verify that the unique string can be found.
    • Test FIA_UAU_EXT.1.1:2: [conditional] The evaluator shall require user authentication according to the AGD guidance. The evaluator shall store a key in the software-based secure key storage.


      The evaluator shall lock the device, use a tool provided by developer to access the key within the stored data, and verify that the key cannot be retrieved or accessed. The evaluator shall enter the Password Authentication Factor to access full device functionality, use a tool provided by developer to access the key, and verify that the key can be retrieved or accessed.
    • Test FIA_UAU_EXT.1.1:3: [conditional] The evaluator shall enable encryption of sensitive data and require user authentication according to the AGD guidance. The evaluator shall write, or the developer shall provide access to, an application that includes a unique string treated as sensitive data.


      The evaluator shall lock the device, use a tool provided by developer to attempt to access the unique string within the application data, and verify that the unique string cannot be found. The evaluator shall enter the Password Authentication Factor to access full device functionality, use a tool provided by developer to access the unique string within the application data, and verify that the unique string can be retrieved.

    FIA_UAU_EXT.2 Timing of Authentication

    The TSF shall allow[selection: [assignment: list of actions ], no actions]on behalf of the user to be performed before the user is authenticated.
    The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user.
    Application Note: The security relevant actions allowed by unauthorized users in locked state must be listed. At a minimum the actions that correspond to the functions available to the user in FMT_SMF.1 and are allowed by unauthorized users in locked state should be listed. For example, if the user can enable/disable the camera per function 5 of FMT_SMF.1 and unauthorized users can take a picture when the device is in locked state, this action must be listed.
    TSS
    The evaluator shall verify that the TSS describes the actions allowed by unauthorized users in the locked state.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    The evaluator shall attempt to perform some actions not listed in the selection while the device is in the locked state and verify that those actions do not succeed.

    FIA_X509_EXT.1 X.509 Validation of Certificates

    The TSF shall validate certificates in accordance with the following rules:
    • RFC 5280 certificate validation and certificate path validation.
    • The certificate path must terminate with a certificate in the Trust Anchor Database.
    • The TSF shall validate a certificate path by ensuring the presence of the basicConstraints extension, that the CA flag is set to TRUE for all CA certificates, and that any path constraints are met.
    • The TSF shall validate that any CA certificate includes caSigning purpose in the key usage field.
    • The TSF shall validate the revocation status of the certificate using [selection: OCSP as specified in RFC 6960, CRL as specified in RFC 5759, an OCSP TLS Status Request Extension (OCSP stapling) as specified in RFC 6066, OCSP TLS Multi-Certificate Status Request Extension (i.e., OCSP Multi-Stapling) as specified in RFC 6961].
    • The TSF shall validate the extendedKeyUsage field according to the following rules:
      • Certificates used for trusted updates and executable code integrity verification shall have the Code Signing Purpose (id-kp 3 with OID 1.3.6.1.5.5.7.3.3) in the extendedKeyUsage field.
      • Server certificates presented for TLS shall have the Server Authentication purpose (id-kp 1 with OID 1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.
      • Server certificates presented for EST shall have the CMC Registration Authority (RA) purpose (id-kp-cmcRA with OID 1.3.6.1.5.5.7.3.28) in the extendedKeyUsage field. [conditional]
      • Client certificates presented for TLS shall have the Client Authentication purpose (id-kp 2 with OID 1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.
      • OCSP certificates presented for OCSP responses shall have the OCSP Signing purpose (id-kp 9 with OID 1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field. [conditional]
    Application Note: FIA_X509_EXT.1.1 lists the rules for validating certificates. The ST author must select whether revocation status is verified using OCSP or CRLs. OCSP stapling and OCSP multi-stapling only support TLS server certificate validation. If other certificate types are validated, either OCSP or CRL should be claimed. The PP-Module for Wireless LAN Clients, version 1.0, to which a MDF TOE must also conform, requires that certificates are used for EAP-TLS; this use requires that the extendedKeyUsage rules are verified. Certificates may optionally be used for trusted updates of system software and applications (FPT_TUD_EXT.2) and for integrity verification (FPT_TST_EXT.2(1)) and, if implemented, must be validated to contain the Code Signing purpose extendedKeyUsage.


    While FIA_X509_EXT.1.1 requires that the TOE perform certain checks on the certificate presented by a TLS server, there are corresponding checks that the authentication server will have to perform on the certificate presented by the client; namely that the extendedKeyUsage field of the client certificate includes “Client Authentication” and that the key agreement bit (for the Diffie-Hellman ciphersuites) or the key encipherment bit (for RSA ciphersuites) be set. Certificates obtained for use by the TOE will have to conform to these requirements in order to be used in the enterprise. This check is required to support EAP-TLS for the PP-Module for Wireless LAN Clients, version 1.0.
    The TSF shall only treat a certificate as a CA certificate if the basicConstraints extension is present and the CA flag is set to TRUE.
    Application Note: This requirement applies to certificates that are used and processed by the TSF and restricts the certificates that may be added to the Trust Anchor Database.
    TSS
    The evaluator shall ensure the TSS describes where the check of validity of the certificates takes place. The evaluator ensures the TSS also provides a description of the certificate path validation algorithm.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
      The tests described must be performed in conjunction with the other Certificate Services evaluation activities, including the use cases in FIA_X509_EXT.2.1 and FIA_X509_EXT.3. The tests for the extendedKeyUsage rules are performed in conjunction with the uses that require those rules. The evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA.
    • Test FIA_X509_EXT.1.2:1: The evaluator shall demonstrate that validating a certificate without a valid certification path results in the function failing, for each of the following reasons, in turn:
      • By establishing a certificate path in which one of the issuing certificates is not a CA certificate,
      • By omitting the basicConstraints field in one of the issuing certificates,
      • By setting the basicConstraints field in an issuing certificate to have CA=False,
      • By omitting the CA signing bit of the key usage field in an issuing certificate, and
      • By setting the path length field of a valid CA field to a value strictly less than the certificate path.
      The evaluator shall then establish a valid certificate path consisting of valid CA certificates, and demonstrate that the function succeeds. The evaluator shall then remove trust in one of the CA certificates, and show that the function fails.
    • Test FIA_X509_EXT.1.2:2: The evaluator shall demonstrate that validating an expired certificate results in the function failing.
    • Test FIA_X509_EXT.1.2:3: The evaluator shall test that the TOE can properly handle revoked certificates-conditional on whether CRL, OCSP, OSCP stapling, or OCSP multi-stapling is selected; if multiple methods are selected, then the following tests shall be performed for each method:


      The evaluator shall test revocation of the node certificate.


      The evaluator shall also test revocation of the intermediate CA certificate (i.e. the intermediate CA certificate should be revoked by the root CA). For the test of the WLAN use case, only pre-stored CRLs are used. If OCSP stapling per RFC 6066 is the only supported revocation method, this test is omitted.


      The evaluator shall ensure that a valid certificate is used, and that the validation function succeeds. The evaluator then attempts the test with a certificate that has been revoked (for each method chosen in the selection) to ensure when the certificate is no longer valid that the validation function fails.

    • Test FIA_X509_EXT.1.2:4: If any OCSP option is selected, the evaluator shall configure the OCSP server or use a man-in-the-middle tool to present a certificate that does not have the OCSP signing purpose and verify that validation of the OCSP response fails. If CRL as specified in RFC 5759 is selected, the evaluator shall configure the CA to sign a CRL with a certificate that does not have the cRLsign key usage bit set, and verify that validation of the CRL fails.
    • Test FIA_X509_EXT.1.2:5: The evaluator shall modify any byte in the first eight bytes of the certificate and demonstrate that the certificate fails to validate (the certificate will fail to parse correctly).
    • Test FIA_X509_EXT.1.2:6: The evaluator shall modify any bit in the last byte of the signature algorithm of the certificate and demonstrate that the certificate fails to validate (the signature on the certificate will not validate).
    • Test FIA_X509_EXT.1.2:7: The evaluator shall modify any byte in the public key of the certificate and demonstrate that the certificate fails to validate (the signature on the certificate will not validate).

    FIA_X509_EXT.2 X.509 Certificate Authentication

    The TSF shall use X.509v3 certificates as defined by RFC 5280 to support authentication for [ mutually authenticated TLS as defined in the Functional Package for Transport Layer Security (TLS), version 1.1, HTTPS, [selection: IPsec in accordance with the PP-Module for Virtual Private Network (VPN) Clients, version 2.4, mutually authenticated DTLS as defined in the Functional Package for Transport Layer Security (TLS), version 1.1, no other protocol] ] and[selection: code signing for system software updates, code signing for mobile applications, code signing for integrity verification, [assignment: other uses ], no additional uses].
    Application Note: The ST author’s first selection must match the selection of FDP_UPC_EXT.1.1/APPS and FTP_ITC_EXT.1.1.


    Certificates may optionally be used for trusted updates of system software ( FPT_TUD_EXT.2.3) and mobile applications ( FPT_TUD_EXT.6.1) and for integrity verification ( FPT_TST_EXT.2.1/PREKERNEL and FPT_TST_EXT.3.1). If code signing for system software updates or code signing for mobile applications is selected FPT_TUD_EXT.4.1 must be included in the ST.


    If code signing for integrity verification is selected FPT_TST_EXT.3.1 must be included in the ST.


    If FPT_TUD_EXT.5.1 is included in the ST, code signing for mobile applications must be included in the selection.
    When the TSF cannot establish a connection to determine the revocation status of a certificate, the TSF shall[selection: allow the administrator to choose whether to accept the certificate in these cases, allow the user to choose whether to accept the certificate in these cases, accept the certificate, not accept the certificate].
    Application Note: The TOE must not accept the certificate if it fails any of the other validation rules in FIA_X509_EXT.1. However, often a connection must be established to perform a verification of the revocation status of a certificate - either to download a CRL or to perform OCSP. The selection is used to describe the behavior in the event that such a connection cannot be established (for example, due to a network error). If the TOE has determined the certificate is valid according to all other rules in FIA_X509_EXT.1, the behavior indicated in the selection must determine the validity. If allow the administrator to choose or allow the user to choose the administrator-configured or user-configured option is selected, the ST author must also select function 30 in FMT_SMF.1.


    The TOE may behave differently depending on the trusted channel; for example, in the case of WLAN where connections are unlikely to be established, the TOE may accept the certificate even though certificates are not accepted for other channels. The ST author should select all applicable behaviors.
    Validation Guidelines:

    Rule #5

    Rule #6
    TSS
    The evaluator shall check the TSS to ensure that it describes how the TOE chooses which certificates to use, and any necessary instructions in the administrative guidance for configuring the operating environment so that the TOE can use the certificates.


    The evaluator shall examine the TSS to confirm that it describes the behavior of the TOE when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. The evaluator shall verify that any distinctions between trusted channels are described.


    Guidance
    If the requirement that the administrator is able to specify the default action, then the evaluator shall ensure that the operational guidance contains instructions on how this configuration action is performed.


    Tests
    • Test FIA_X509_EXT.2.2:1: The evaluator shall demonstrate that using a valid certificate that requires certificate validation checking to be performed in at least some part by communicating with a non-TOE IT entity. The evaluator shall then manipulate the environment so that the TOE is unable to verify the validity of the certificate, and observe that the action selected in FIA_X509_EXT.2.2 is performed. If the selected action is administrator-configurable, then the evaluator shall follow the operational guidance to determine that all supported administrator-configurable options behave in their documented manner.

    FIA_X509_EXT.3 Request Validation of Certificates

    The TSF shall provide a certificate validation service to applications.
    The TSF shall respond to the requesting application with the success or failure of the validation.
    Application Note: In order to comply with all of the rules in FIA_X509_EXT.1, multiple API calls may be required; all of these calls should be clearly documented
    The evaluator shall verify that the API documentation provided according to includes the security function (certificate validation) described in this requirement. This documentation shall be clear as to which results indicate success and failure.
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    The evaluator shall write, or the developer shall provide access to, an application that requests certificate validation by the TSF. The evaluator shall verify that the results from the validation match the expected results according to the API documentation. This application may be used to verify that import, removal, modification, and validation are performed correctly according to the tests required by FDP_STG_EXT.1, FTP_ITC_EXT.1, FMT_SMF.1, and FIA_X509_EXT.1.

    5.1.6 Class: Security Management (FMT)

    Both the user and the administrator may manage the TOE. This administrator is likely to be acting remotely and could be the Mobile Device Management (MDM) Administrator acting through an MDM Agent.


    The Administrator is responsible for management activities, including setting the policy that is applied by the enterprise on the Mobile Device. These management functions are likely to be a different set than those management functions provided to the user. Management functions that are provided to the user and not the administrator are listed in FMT_MOF_EXT.1.1. Management functions for which the administrator may adopt a policy that restricts the user from performing that function are listed in FMT_MOF_EXT.1.2.


    Table 6Table 6 compares the management functions required by this Protection Profile in the following three requirements (FMT_MOF_EXT.1.1, FMT_MOF_EXT.1.2, and FMT_SMF.1).

    FMT_MOF_EXT.1 Management of Security Functions Behavior

    The TSF shall restrict the ability to perform the functions [ in column 4 of Table 6Table 6 ] to the user.
    Application Note: The functions that have an "M" in the fourth column are mandatory for this component, thus are restricted to the user, meaning that the administrator cannot manage those functions. The functions that have an "O" in the fourth column are optional and may be selected; and those functions with a "-" are not applicable and may not be selected. The ST author should select those security management functions that only the user may perform (i.e. the ones the administrator may not perform).


    The ST author may not select the same function in both FMT_MOF_EXT.1.1 and FMT_MOF_EXT.1.2. A function cannot contain an "M" in both column 4 and column 6.


    The ST author may use a table in the ST, indicating with clear demarcations (to be accompanied by an index) those functions that are restricted to the user (column 4). The ST author should iterate a row to indicate any variations in the selectable sub-functions or assigned values with respect to the values in the columns.


    For functions that are mandatory, any sub-functions not in a selection are also mandatory and any assignments must contain at least one assigned value. For non-selectable sub-functions in an optional function, all sub-functions outside a selection must be implemented in order for the function to be listed.
    The TSF shall restrict the ability to perform the functions [ in column 6 of Table 6Table 6 ] to the administrator when the device is enrolled and according to the administrator-configured policy.
    Application Note: As long as the device is enrolled in management, the administrator (of the enterprise) must be guaranteed that minimum security functions of the enterprise policy are enforced. Further restrictive policies can be applied at any time by the user on behalf of the user or other administrators.


    The functions that have an "M" in the sixth column are mandatory for this component; the functions that have an "O" in the sixth column are optional and may be selected; and those functions with a "-" in the sixth are not applicable and may not be selected.


    The ST author may not select the same function in both FMT_MOF_EXT.1.1 and FMT_MOF_EXT.1.2.


    The ST author should select those security management functions that the administrator may restrict. The ST author may use a table in the ST, indicating with clear demarcations (to be accompanied by an index) those functions that are and are not implemented with APIs for the administrator (as in column 5). Additionally, the ST author should demarcate which functions the user is prevented from accessing or performing (as in column 6). The ST author should iterate a row to indicate any variations in the selectable sub-functions or assigned values with respect to the values in the columns.


    For functions that are mandatory, any sub-functions not in a selection are also mandatory and any assignments must contain at least one assigned value. For non-selectable sub-functions in an optional function, all sub-functions outside the selection must be implemented in order for the function to be listed.
    TSS
    The evaluator shall verify that the TSS describes those management functions that may only be performed by the user and confirm that the TSS does not include an Administrator API for any of these management functions. This activity will be performed in conjunction with FMT_SMF.1.


    Guidance
    There are no guidance evaluation activities for this element.


    Tests
    There are no test evaluation activities for this element.


    TSS
    The evaluator shall verify that the TSS describes those management functions that may be performed by the Administrator, to include how the user is prevented from accessing, performing, or relaxing the function (if applicable), and how applications/APIs are prevented from modifying the Administrator configuration. The TSS also describes any functionality that is affected by administrator-configured policy and how. This activity will be performed in conjunction with FMT_SMF.1.


    Guidance
    There are no guidance evaluation activities for this element.


    Tests
    • Test FMT_MOF_EXT.1.2:1: The evaluator shall use the test environment to deploy policies to Mobile Devices.
    • Test FMT_MOF_EXT.1.2:2: The evaluator shall create policies which collectively include all management functions which are controlled by the (enterprise) administrator and cannot be overridden/relaxed by the user as defined in FMT_MOF_EXT.1.2. The evaluator shall apply these policies to devices, attempt to override/relax each setting both as the user (if a setting is available) and as an application (if an API is available), and ensure that the TSF does not permit it. Note that the user may still apply a more restrictive policy than that of the administrator.
    • Test FMT_MOF_EXT.1.2:3: Additional testing of functions provided to the administrator are performed in conjunction with the testing activities for FMT_SMF.1.1.

    FMT_SMF.1 Specification of Management Functions


    The TSF shall be capable of performing the following management functions:


    Table 5: Management Functions


    Status Markers:

    M - Mandatory

    O - Optional/Objective

    #Management FunctionImpl.User OnlyAdminAdmin Only
    1 configure password policy:
    • Minimum password length
    • Minimum password complexity
    • Maximum password lifetime
    MMandatory
    -N/A
    MMandatory
    MMandatory
    2 configure session locking policy:
    • Screen-lock enabled/disabled
    • Screen lock timeout
    • Number of authentication failures
    MMandatory
    -N/A
    MMandatory
    MMandatory
    3 enable/disable the VPN protection:
    • Across device
    [selection:
    • on a per-app basis
    • on a per-group of applications processes basis
    • no other method
    ]
    MMandatory
    OOptional
    OOptional
    OOptional
    4 enable/disable [assignment: list of all radios]
    MMandatory
    OOptional
    OOptional
    OOptional
    5 enable/disable [assignment: list of audio or visual collection devices]:
    • Across device
    [selection:
    • on a per-app basis
    • on a per-group of applications processes basis
    • no other method
    ]
    MMandatory
    OOptional
    OOptional
    OOptional
    6 transition to the locked state
    MMandatory
    -N/A
    MMandatory
    -N/A
    7 TSF wipe of protected data
    MMandatory
    -N/A
    MMandatory
    -N/A
    8 configure application installation policy by
    [selection:
    • restricting the sources of applications
    • specifying a set of allowed applications based on [assignment: application characteristics] (an application allowlist)
    • denying installation of applications
    ]
    MMandatory
    -N/A
    MMandatory
    MMandatory
    9 import keys or secrets into the secure key storage
    MMandatory
    OOptional
    OOptional
    -N/A
    10 destroy imported keys or secrets and [selection: no other keys or secrets, [assignment: list of other categories of keys or secrets]] in the secure key storage
    MMandatory
    OOptional
    OOptional
    -N/A
    11 import X.509v3 certificates into the Trust Anchor Database
    MMandatory
    -N/A
    MMandatory
    OOptional
    12 remove imported X.509v3 certificates and [selection: no other X.509v3 certificates, [assignment: list of other categories of X.509v3 certificates]] in the Trust Anchor Database
    MMandatory
    OOptional
    OOptional
    -N/A
    13 enroll the TOE in management
    MMandatory
    OOptional
    OOptional
    OOptional
    14 remove applications
    MMandatory
    -N/A
    MMandatory
    OOptional
    15 update system software
    MMandatory
    -N/A
    MMandatory
    OOptional
    16 install applications
    MMandatory
    -N/A
    MMandatory
    OOptional
    17 remove Enterprise applications
    MMandatory
    -N/A
    MMandatory
    -N/A
    18 enable/disable display notification in the locked state of: [selection:
    • email notifications
    • calendar appointments
    • contact associated with phone call notification
    • text message notification
    • [assignment: other application-based notifications]
    • all notifications
    ]
    MMandatory
    OOptional
    OOptional
    OOptional
    19 enable data-at rest protection
    MMandatory
    OOptional
    OOptional
    OOptional
    20 enable removable media’s data-at-rest protection
    MMandatory
    OOptional
    OOptional
    OOptional
    21 enable/disable location services:
    • Across device
    [selection:
    • on a per-app basis
    • on a per-group of applications processes basis
    • no other method
    ]
    MMandatory
    OOptional
    OOptional
    OOptional
    22 enable/disable the use of [selection: Biometric Authentication Factor, Hybrid Authentication Factor]
    OOptional
    OOptional
    OOptional
    OOptional
    23 configure whether to allow or disallow establishment of [assignment: configurable trusted channel in FTP_ITC_EXT.1.1 or FDP_UPC_EXT.1.1/APPS] if the peer or server certificate is deemed invalid.
    OOptional
    OOptional
    OOptional
    OOptional
    24 enable/disable all data signaling over [assignment: list of externally accessible hardware ports]
    OOptional
    OOptional
    OOptional
    OOptional
    25 enable/disable [assignment: list of protocols where the device acts as a server]
    OOptional
    OOptional
    OOptional
    OOptional
    26 enable/disable developer modes
    OOptional
    OOptional
    OOptional
    OOptional
    27 enable/disable bypass of local user authentication
    OOptional
    OOptional
    OOptional
    OOptional
    28 wipe Enterprise data
    OOptional
    OOptional
    OOptional
    -N/A
    29 approve [selection: import, removal] by applications of X.509v3 certificates in the Trust Anchor Database
    OOptional
    OOptional
    OOptional
    OOptional
    30 configure whether to allow or disallow establishment of a trusted channel if the TSF cannot establish a connection to determine the validity of a certificate
    OOptional
    OOptional
    OOptional
    OOptional
    31 enable/disable the cellular protocols used to connect to cellular network base stations
    OOptional
    OOptional
    OOptional
    OOptional
    32 read audit logs kept by the TSF
    OOptional
    OOptional
    OOptional
    -N/A
    33 configure [selection: certificate, public-key] used to validate digital signature on applications
    OOptional
    OOptional
    OOptional
    OOptional
    34 approve exceptions for shared use of keys or secrets by multiple applications
    OOptional
    OOptional
    OOptional
    OOptional
    35 approve exceptions for destruction of keys or secrets by applications that did not import the key or secret
    OOptional
    OOptional
    OOptional
    OOptional
    36 configure the unlock banner
    MMandatory
    -N/A
    OOptional
    OOptional
    37 configure the auditable items
    OOptional
    -N/A
    OOptional
    OOptional
    38 retrieve TSF-software integrity verification values
    OOptional
    OOptional
    OOptional
    OOptional
    39 enable/disable [selection:
    • USB mass storage mode
    • USB data transfer without user authentication
    • USB data transfer without authentication of the connecting system
    ]
    OOptional
    OOptional
    OOptional
    OOptional
    40 enable/disable backup of [selection: all applications, selected applications, selected groups of applications, configuration data] to [selection: locally connected system, remote system]
    OOptional
    OOptional
    OOptional
    OOptional
    41 enable/disable [selection:
    • Hotspot functionality authenticated by [selection: pre-shared key, passcode, no authentication]
    • USB tethering authenticated by [selection: pre-shared key, passcode, no authentication]
    ]
    OOptional
    OOptional
    OOptional
    OOptional
    42 approve exceptions for sharing data between [selection: applications, groups of applications]
    OOptional
    OOptional
    OOptional
    OOptional
    43 place applications into application groups based on [assignment: enterprise configuration settings]
    OOptional
    OOptional
    OOptional
    OOptional
    44 unenroll the TOE from management
    OOptional
    OOptional
    OOptional
    OOptional
    45 enable/disable the Always On VPN protection:
    • Across device
    [selection:
    • on a per-app basis
    • on a per-group of applications processes basis
    • no other method
    ]
    OOptional
    OOptional
    OOptional
    OOptional
    46 revoke Biometric template
    OOptional
    OOptional
    OOptional
    OOptional
    47[assignment: list of other management functions to be provided by the TSF]
    OOptional
    OOptional
    OOptional
    OOptional
    The TSF shall be capable of performing the following management functions: Table 6: Management Functions Status Markers: M - Mandatory O - Optional/Objective
    Application Note: Table 6Table 6 compares the management functions required by this Protection Profile.


    The first column lists the management functions identified in the PP.


    In the following columns:
    • ‘M’ means Mandatory
    • ‘O’ means Optional/Objective
    • '-' means that no value (M or O) can be assigned


    The third column ("Impl.") indicates whether the function is to be implemented. The ST author should select which Optional functions are implemented.


    The fourth column ("User Only") indicates functions that are to be restricted to the user (i.e. not available to the administrator).


    The fifth column ("Admin") indicates functions that are available to the administrator. The functions restricted to the user (column 4) cannot also be available to the administrator. Functions available to the administrator can still be available to the user, as long as the function is not restricted to the administrator (column 6). Thus, if the TOE must offer these functions to the administrator to perform, the fifth column must be selected.


    The sixth column (FMT_MOF_EXT.1.2) indicates whether the function is to be restricted to the administrator when the device is enrolled and the administrator applies the indicated policy. If the function is restricted to the administrator the function is not available to the user. This does not prevent the user from modifying a setting to make the function stricter, but the user cannot undo the configuration enforced by the administrator.


    The ST author may use a table in the ST, listing only those functions that are implemented. For functions that are mandatory, any sub-functions not in a selection are also mandatory and any assignments must contain at least one assigned value. For functions that are optional and contain an assignment or selection, at least one value must be assigned/selected to be included in the ST. For non-selectable sub-functions in an optional function, all sub-functions must be implemented in order for the function to be included. For functions with a "per-app basis" sub function and an assignment, the ST author must indicate which assigned features are manageable on a per-app basis and which are not by iterating the row.




    Function-specific Application Notes:


    Functions 3 , 5 , and 21 must be implemented on a device-wide basis but may also be implemented on a per-app basis or on a per-group of applications basis in which the configuration includes the list of applications or groups of applications to which the enable/disable applies.

    Function 3 addresses enabling and disabling the IPsec VPN only. The configuration of the VPN Client itself (with information such as VPN Gateway, certificates, and algorithms) is addressed by the PP-Module for Virtual Private Network (VPN) Clients, version 2.4. The administrator options should only be listed if the administrator can remotely enable/disable the VPN connection.

    Function 3 optionally allows the VPN to be configured per-app or per-groups of apps. If this configuration is selected, it does not void FDP_IFC_EXT.1. Instead FDP_IFC_EXT.1 is applied to the application or group of applications the VPN is applied to. In other words, all traffic destined for the VPN-enabled application or group of applications, must travel through the VPN, but traffic not destined for that application or group of applications can travel outside the VPN. When the VPN is configured across the device FDP_IFC_EXT.1 applies to all traffic and the VPN must not split tunnel.

    The assignment in function 4 consists of all radios present on the TSF, such as Wi-Fi, cellular, NFC, Bluetooth BR/EDR, and Bluetooth LE, which can be enabled and disabled. In the future, if both Bluetooth BR/EDR and Bluetooth LE are supported, they will be required to be enabled and disabled separately. Disablement of the cellular radio does not imply that the radio may not be enabled in order to place emergency phone calls; however, it is not expected that a device in "airplane mode", where all radios are disabled, will automatically (without authorization) turn on the cellular radio to place emergency calls.

    The assignment in function 5 consists of at least one audio or visual device, such as camera and microphone, which can be enabled and disabled by either the user or administrator. Disablement of the microphone does not imply that the microphone may not be enabled in order to place emergency phone calls. If certain devices are able to be restricted to the enterprise (either device-wide, per-app or per-group of applications) and others are able to be restricted to users, then this function should be iterated in the table with the appropriate table entries.

    Regarding functions 4 and 5, disablement of a particular radio or audio/visual device must be effective as soon as the TOE has power. Disablement must also apply when the TOE is booted into auxiliary boot modes, for example, associated with updates or backup. If the TOE supports states in which security management policy is inaccessible, for example, due to data-at-rest protection, it is acceptable to meet this requirement by ensuring that these devices are disabled by default while in these states. That these devices are disabled during auxiliary boot modes does not imply that the device (particularly the cellular radio) may not be enabled in order to perform emergency phone calls.

    Wipe of the TSF (function 7) is performed according to FCS_CKM_EXT.5. Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well.

    The selection in function 8 allows the ST author to select which mechanisms are available to the administrator through the MDM Agent to restrict the applications which the user may install. The ST author must state if application allowlist is applied device-wide or if it can be specified to apply to either the Enterprise or Personal applications.

    • If the administrator can restrict the sources from which applications can be installed, the ST author selects "restricting the sources of applications".
    • If the administrator can specify a allowlist of allowed applications, the ST author selects "application allowlist". The ST author should list any application characteristics (e.g. name, version, or developer) based on which the allowlist can be formed.
    • If the administrator can prevent the user from installing additional applications, the ST author selects "denying installation of applications".

    In the future, function 12 may require destruction or disabling of any default trusted CA certificates, excepting those CA certificates necessary for continued operation of the TSF, such as the developer’s certificate. At this time, the ST author must indicate in the assignment whether pre-installed or any other category of X.509v3 certificates may be removed from the Trust Anchor Database.

    For function 13, the enrollment function may be installing an MDM agent and includes the policies to be applied to the device. It is acceptable for the user approval notice to require the user to intentionally opt to view the policies (for example, by "tapping" on a "View" icon) rather than listing the policies in full in the notice.

    For function 15, the administrator capability to update the system software may be limited to causing a prompt to the user to update rather than the ability to initiate the update itself. As the administrator is likely to be acting remotely, he/she would be unaware of inopportune situations, such as low power, which may cause the update to fail and the device to become inoperable. The user can refuse to accept the update in such situations. It is expected that system architects will be cognizant of this limitation and will enforce network access controls in order to enforce enterprise-critical updates.

    Function 16 addresses both installation and update. This protection profile does not distinguish between installation and update of applications because mobile devices typically completely overwrite the previous installation with a new installation during an application update.

    For function 17, "Enterprise applications" are those applications that belong to the Enterprise application group. Applications installed by the enterprise administrator (including automatic installation by the administrator after being requested by the user from a catalog of enterprise applications) are by default placed in the Enterprise application group unless an exception has been made in function 43 of FMT_SMF.1.1.

    If the display of notifications in the locked state is supported, the configuration of these notifications (function 18) must be included in the selection.

    Function 19 must be included in the selection if data-at-rest protection is not natively enabled.

    Function 20 is implicitly met if the TSF does not support removable media.

    For function 21, location services include location information gathered from GPS, cellular, and Wi-Fi.

    Function 22 must be included in the ST if the TOE contains a BAF. This selection must correspond with the selection made in FIA_UAU.5.1. If biometric in accordance with the Biometric Enrollment and Verification, version 1.1 is selected in FIA_UAU.5.1, "Biometric Authentication Factor" must be selected and the user or admin must have the option to disable the use of it. If multiple BAFs are claimed in FIA_MBV_EXT.1.1 in the Biometric Enrollment and Verification, version 1.1, this applies to all different modalities. If hybrid is selected in FIA_UAU.5.1 it must be selected and the user or admin must have the option to disable the use of it.

    Function 23 must be included in the ST if the function is configurable on the TOE for any of the trusted channels either mandated or selected in FTP_ITC_EXT.1.1 or FDP_UPC_EXT.1.1/APPS. The configuration can be different depending on the specific trusted channel(s) and they must be filled in for the assignment.

    The assignment in function 24 consists of all externally accessible hardware ports, such as USB, the SD card, and HDMI, whose data transfer capabilities can be enabled and disabled by either the user or administrator. Disablement of data transfer over an external port must be effective during and after boot into the normal operative mode of the device. If the TOE supports states in which configured security management policy is inaccessible, for example, due to data-at-rest protection, it is acceptable to meet this requirement by ensuring that data transfer is disabled by default while in these states. Each of the ports may be enabled or disabled separately. The configuration policy need not disable all ports together. In the case of USB, charging is still allowed if data transfer capabilities have been disabled.

    The assignment in function 25 consists of all protocols where the TSF acts as a server, which can be enabled and disabled by either the user or administrator.

    Function 26 must be included in the selection if developer modes are supported by the TSF.

    Function 27 must be included in the selection if bypass of local user authentication, such as a "Forgot Password", password hint, or remote authentication feature, is supported.

    Function 29 must be included in the selection if the TSF allows applications, other than the MDM Agents, to import or remove X.509v3 certificates from the Trust Anchor Database. The MDM Agent is considered the administrator. This function does not apply to applications trusting a certificate for its own validations. The function only applies to situations where the application modifies the device-wide Trust Anchor Database, affecting the validations performed by the TSF for other applications. The user or administrator may be provided the ability to globally allow or deny any application requests in order to meet this requirement.

    Function 30 must be included in the ST if "administrator-configured option" is selection in FIA_X509_EXT.2.2.

    Function 33 should be included in the selection if FPT_TUD_EXT.5.1 is included in the ST and the configurable option is selected.

    Function 34 should be included in the selection if user or administrator is selected in FCS_STG_EXT.1.4.

    Function 35 should be included in the selection if the user or the administrator is selected in FCS_STG_EXT.1.5.

    Function 37 must be included in the selection if FAU_SEL.1 is included in the ST.

    For function 41, hotspot functionality refers to the condition in which the mobile device is serving as an access point to other devices, not the connection of the TOE to external hotspots.

    Functions 42 and 43 correspond to FDP_ACF_EXT.1.2.

    For function 44, FMT_SMF_EXT.2.1 specifies actions to be performed when the TOE is unenrolled from management.

    Function 45 must be included in the ST if IPsec is selected in FTP_ITC_EXT.1 and the native IPsec VPN client can be configured to be Always-On. Always-On is defined as when the TOE has a network connection the VPN attempts to connect, all data leaving the device uses the VPN when the VPN is connected and no data leaves that device when the VPN is disconnected. The configuration of the VPN Client itself (with information such as VPN Gateway, certificates, and algorithms) is addressed by the PP-Module for Virtual Private Network (VPN) Clients, version 2.4.

    Validation Guidelines:

    Rule #5

    Rule #6

    Rule #7

    Rule #8
    TSS
    The evaluator shall verify the TSS defines the allowable policy options: the range of values for both password length and lifetime, and a description of complexity to include character set and complexity policies (e.g., configuration and enforcement of number of uppercase, lowercase, and special characters per password).
    Tests
    The evaluator shall exercise the TSF configuration as the administrator and perform positive and negative tests, with at least two values set for each variable setting, for each of the following:

    • Minimum password length
    • Minimum password complexity
    • Maximum password lifetime
    The following EAs correspond to specific management functions.
    Function 1

    TSS
    The evaluator shall verify the TSS defines the allowable policy options: the range of values for both password length and lifetime, and a description of complexity to include character set and complexity policies (e.g., configuration and enforcement of number of uppercase, lowercase, and special characters per password).
    Tests
    The evaluator shall exercise the TSF configuration as the administrator and perform positive and negative tests, with at least two values set for each variable setting, for each of the following:

    • Minimum password length
    • Minimum password complexity
    • Maximum password lifetime

    Function 2

    TSS
    The evaluator shall verify the TSS defines the range of values for both timeout period and number of authentication failures for all supported authentication mechanisms.
    Tests
    The evaluator shall exercise the TSF configuration as the administrator. The evaluator shall perform positive and negative tests, with at least two values set for each variable setting, for each of the following:

    • Screen-lock enabled/disabled
    • Screen lock timeout
    • Number of authentication failures (may be combined with test for FIA_AFL_EXT.1)

    Function 3

    Tests
    The evaluator shall perform the following tests:
    • Test FMT_SMF.1.1:1: The evaluator shall exercise the TSF configuration to enable the VPN protection. These configuration actions must be used for the testing of the FDP_IFC_EXT.1.1 requirement.
    • Test FMT_SMF.1.1:2: [conditional] If "on a per-app basis" is selected, the evaluator shall create two applications and enable one to use the VPN and the other to not use the VPN. The evaluator shall exercise each application (attempting to access network resources; for example, by browsing different websites) individually while capturing packets from the TOE. The evaluator shall verify from the packet capture that the traffic from the VPN-enabled application is encapsulated in IPsec and that the traffic from the VPN-disabled application is not encapsulated in IPsec.
    • Test FMT_SMF.1.1:3: [conditional] If "on a per-group of applications processes basis" is selected, the evaluator shall create two applications and the applications shall be placed into different groups. Enable one application group to use the VPN and the other to not use the VPN. The evaluator shall exercise each application (attempting to access network resources; for example, by browsing different websites) individually while capturing packets from the TOE. The evaluator shall verify from the packet capture that the traffic from the application in the VPN-enabled group is encapsulated in IPsec and that the traffic from the application in the VPN-disabled group is not encapsulated in IPsec.

    Function 4

    TSS
    The evaluator shall verify that the TSS includes a description of each radio and an indication of if the radio can be enabled/disabled along with what role can do so. In addition the evaluator shall verify that the frequency ranges at which each radio operates is included in the TSS. The evaluator shall verify that the TSS includes at what point in the boot sequence the radios are powered on and indicates if the radios are used as part of the initialization of the device.
    Guidance
    The evaluator shall confirm that the AGD guidance describes how to perform the enable/disable function for each radio.


    Tests
    The evaluator shall ensure that minimal signal leakage enters the RF shielded enclosure (i.e. Faraday bag, Faraday box, RF shielded room) by performing the following steps:


    Step 1: Place the antenna of the spectrum analyzer inside the RF shielded enclosure.


    Step 2: Enable "Max Hold" on the spectrum analyzer and perform a spectrum sweep of the frequency range between 300 MHz – 6000 MHz, in I kHz steps (this range should encompass 802.11, 802.15, GSM, UMTS, and LTE). This range will not address NFC 13.56.MHz, another test should be set up with similar constraints to address NFC.


    If power above -90 dBm is observed, the Faraday box has too great of signal leakage and shall not be used to complete the test for Function 4. The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable and disable the state of each radio (e.g. Wi-Fi, cellular, NFC, Bluetooth). Additionally, the evaluator shall repeat the steps below, booting into any auxiliary boot mode supported by the device. For each radio, the evaluator shall:


    Step 1: Place the antenna of the spectrum analyzer inside the RF shielded enclosure. Configure the spectrum analyzer to sweep desired frequency range for the radio to be tested (based on range provided in the TSS)). The ambient noise floor shall be set to -110 dBm. Place the TOE into the RF shielded enclosure to isolate them from all other RF traffic.


    Step 2: The evaluator shall create a baseline of the expected behavior of RF signals. The evaluator shall power on the device, ensure the radio in question is enabled, power off the device, enable "Max Hold" on the spectrum analyzer and power on the device. The evaluator shall wait 2 minutes at each Authentication Factor interface prior to entering the necessary password to complete the boot process, waiting 5 minutes after the device is fully booted. The evaluator shall observe that RF spikes are present at the expected uplink channel frequency. The evaluator shall clear the "Max Hold" on the spectrum analyzer.


    Step 3: The evaluator shall verify the absence of RF activity for the uplink channel when the radio in question is disabled. The evaluator shall complete the following test five times. The evaluator shall power on the device, ensure the radio in question is disabled, power off the device, enable "Max Hold" on the spectrum analyzer and power on the device. The evaluator shall wait 2 minutes at each Authentication Factor interface prior to entering the necessary password to complete the boot process, waiting 5 minutes after the device is fully booted. The evaluator shall clear the "Max Hold" on the spectrum analyzer. If the radios are used for device initialization, then a spike of RF activity for the uplink channel can be observed initially at device boot. However, if a spike of RF activity for the uplink channel of the specific radio frequency band is observed after the device is fully booted or at an Authentication Factor interface it is deemed that the radio is enabled.

    Function 5

    TSS
    The evaluator shall verify that the TSS includes a description of each collection device and an indication of if it can be enabled/disabled along with what role can do so. The evaluator shall confirm that the AGD guidance describes how to perform the enable/disable function.
    Tests
    The evaluator shall perform the following tests:
    • Test FMT_SMF.1.1:4: The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable and disable the state of each audio or visual collection devices (e.g. camera, microphone) listed by the ST author. For each collection device, the evaluator shall disable the device and then attempt to use its functionality. The evaluator shall reboot the TOE and verify that disabled collection devices may not be used during or early in the boot process. Additionally, the evaluator shall boot the device into each available auxiliary boot mode and verify that the collection device cannot be used.
    • Test FMT_SMF.1.1:5: [conditional] If "on a per-app basis" is selected, the evaluator shall create two applications and enable one to use access the A/V device and the other to not access the A/V device. The evaluator shall exercise each application attempting to access the A/V device individually. The evaluator shall verify that the enabled application is able to access the A/V device and the disabled application is not able to access the A/V device.
    • Test FMT_SMF.1.1:6: [conditional] If "on a per-group of applications processes basis" is selected, the evaluator shall create two applications and the applications shall be placed into different groups. Enable one group to access the A/V device and the other to not access the A/V device. The evaluator shall exercise each application attempting to access the A/V device individually. The evaluator shall verify that the application in the enabled group is able to access the A/V device and the application in the disabled group is not able to access the A/V device.

    Function 6

    Tests
    The evaluator shall use the test environment to instruct the TSF, both as a user and as the administrator, to command the device to transition to a locked state, and verify that the device transitions to the locked state upon command.

    Function 7

    Tests
    The evaluator shall use the test environment to instruct the TSF, both as a user and as the administrator, to command the device to perform a wipe of protected data. The evaluator must ensure that this management setup is used when conducting the Evaluation Activities in FCS_CKM_EXT.5.

    Function 8

    TSS
    The evaluator shall verify the TSS describes the allowable application installation policy options based on the selection included in the ST. If the application allowlist is selected, the evaluator shall verify that the TSS includes a description of each application characteristic upon which the allowlist may be based.
    Tests
    The evaluator shall exercise the TSF configuration as the administrator to restrict particular applications, sources of applications, or application installation according to the AGD guidance. The evaluator shall attempt to install unauthorized applications and ensure that this is not possible. The evaluator shall, in conjunction, perform the following specific tests:
    • Test FMT_SMF.1.1:7: [conditional] The evaluator shall attempt to connect to an unauthorized repository in order to install applications.
    • Test FMT_SMF.1.1:8: [conditional] The evaluator shall attempt to install two applications (one allowlisted, and one not) from a known allowed repository and verify that the application not on the allowlist is rejected. The evaluator shall also attempt to side-load executables or installation packages via USB connections to determine that the white list is still adhered to

    Functions 9/10

    TSS
    The evaluator shall verify that the TSS describes each category of keys or secrets that can be imported into the TSF’s secure key storage.
    Tests
    The test of these functions is performed in association with FCS_STG_EXT.1.

    Function 11

    Guidance
    The evaluator shall review the AGD guidance to determine that it describes the steps needed to import, modify, or remove certificates in the Trust Anchor database, and that the users that have authority to import those certificates (e.g., only administrator, or both administrators and users) are identified.
    Tests
    The evaluator shall import certificates according to the AGD guidance as the user or as the administrator, as determined by the administrative guidance. The evaluator shall verify that no errors occur during import. The evaluator should perform an action requiring use of the X.509v3 certificate to provide assurance that installation was completed properly.

    Function 12

    TSS
    The evaluator shall verify that the TSS describes each additional category of X.509 certificates and their use within the TSF.
    Tests
    The evaluator shall remove an administrator-imported certificate and any other categories of certificates included in the assignment of function 14 from the Trust Anchor Database according to the AGD guidance as the user and as the administrator.

    Function 13

    TSS
    The evaluator shall examine the TSS to ensure that it contains a description of each management function that will be enforced by the enterprise once the device is enrolled. The evaluator shall examine the AGD guidance to determine that this same information is present.
    Tests
    The evaluator shall verify that user approval is required to enroll the device into management.

    Function 14

    TSS
    The evaluator shall verify that the TSS includes an indication of what applications (e.g., user-installed applications, Administrator-installed applications, or Enterprise applications) can be removed along with what role can do so. The evaluator shall examine the AGD guidance to determine that it details, for each type of application that can be removed, the procedures necessary to remove those applications and their associated data. For the purposes of this Evaluation Activity, "associated data" refers to data that are created by the app during its operation that do not exist independent of the app's existence, for instance, configuration data, or e-mail information that’s part of an e-mail client. It does not, on the other hand, refer to data such as word processing documents (for a word processing app) or photos (for a photo or camera app).
    Tests
    The evaluator shall attempt to remove applications according to the AGD guidance and verify that the TOE no longer permits users to access those applications or their associated data.

    Function 15

    Tests
    The evaluator shall attempt to update the TSF system software following the procedures in the AGD guidance and verify that updates correctly install and that the version numbers of the system software increase.

    Function 16

    Tests
    The evaluator shall attempt to install an application following the procedures in the AGD guidance and verify that the application is installed and available on the TOE.

    Function 17

    Tests
    The evaluator shall attempt to remove any Enterprise applications from the device by following the administrator guidance. The evaluator shall verify that the TOE no longer permits users to access those applications or their associated data.

    Function 18

    Guidance
    The evaluator shall examine the AGD Guidance to determine that it specifies, for at least each category of information selected for Function 18, how to enable and disable display information for that type of information in the locked state.
    Tests
    For each category of information listed in the AGD guidance, the evaluator shall verify that when that TSF is configured to limit the information according to the AGD, the information is no longer displayed in the locked state.

    Function 19

    Tests
    The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable system-wide data-at-rest protection according to the AGD guidance. The evaluator shall ensure that all Evaluation Activities for DAR (FDP_DAR) are conducted with the device in this configuration.

    Function 20

    Tests
    The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable removable media’s data-at-rest protection according to the AGD guidance. The evaluator shall ensure that all Evaluation Activities for DAR (FDP_DAR) are conducted with the device in this configuration.

    Function 21

    Tests
    The evaluator shall perform the following tests.
    • Test FMT_SMF.1.1:9: The evaluator shall enable location services device-wide and shall verify that an application (such as a mapping application) is able to access the TOE’s location information. The evaluator shall disable location services device-wide and shall verify that an application (such as a mapping application) is unable to access the TOE’s location information.
    • Test FMT_SMF.1.1:10: [conditional] If on a per-app basis is selected, the evaluator shall create two applications and enable one to use access the location services and the other to not access the location services. The evaluator shall exercise each application attempting to access location services individually. The evaluator shall verify that the enabled application is able to access the location services and the disabled application is not able to access the location services.

    Function 22 [CONDITIONAL]

    Tests
    The evaluator shall verify that the TSS states if the TOE supports a BAF or hybrid authentication. If the TOE does not include a BAF or hybrid authentication this test is implicitly met.
    • Test FMT_SMF.1.1:11: [conditional] If biometric in accordance with the Biometric Enrollment and Verification, version 1.1 is selected in FIA_UAU.5.1, for each BAF claimed in FIA_MBV_EXT.1.1 in the Biometric Enrollment and Verification, version 1.1 the evaluator shall verify that the TSS describes the procedure to enable/disable the BAF. The evaluator shall configure the TOE to allow each supported BAF to authenticate and verify that successful authentication can be achieved using the BAF. The evaluator shall configure the TOE to disable the use of each supported BAF for authentication and confirm that the BAF cannot be used to authenticate.
    • Test FMT_SMF.1.1:12: [conditional] If hybrid is selected the evaluator shall verify that the TSS describes the procedure to enable/disable the hybrid (biometric credential and PIN/password) authentication. The evaluator shall configure the TOE to allow hybrid authentication to authenticate and confirm that successful authentication can be achieved using the hybrid authentication. The evaluator shall configure the TOE to disable the use of hybrid authentication and confirm that the hybrid authentication cannot be used to authenticate.

    Function 23 [CONDITIONAL]

    Tests
    The test of this function is performed in conjunction with FIA_X509_EXT.2.2, FCS_TLSC_EXT.1.3 in the Functional Package for Transport Layer Security (TLS), version 1.1.

    Function 24 [CONDITIONAL]

    TSS
    The evaluator shall verify that the TSS includes a list of each externally accessible hardware port and an indication of if data transfer over that port can be enabled/disabled. AGD guidance will describe how to perform the enable/disable function.
    Tests
    The evaluator shall exercise the TSF configuration to enable and disable data transfer capabilities over each externally accessible hardware ports (e.g. USB, SD card, HDMI) listed by the ST author. The evaluator shall use test equipment for the particular interface to ensure that while the TOE may continue to receive data on the RX pins, it is not responding on TX pins used for data transfer when they are disabled. For each disabled data transfer capability, the evaluator shall repeat this test by rebooting the device into the normal operational mode and verifying that the capability is disabled throughout the boot and early execution stage of the device.

    Function 25 [CONDITIONAL]

    TSS
    The evaluator shall verify that the TSS describes how the TSF acts as a server in each of the protocols listed in the ST, and the reason for acting as a server.
    Tests
    The evaluator shall attempt to disable each listed protocol in the assignment. The evaluator shall verify that remote devices can no longer access the TOE or TOE resources using any disabled protocols.

    Function 26 [CONDITIONAL]

    Tests
    The evaluator shall exercise the TSF configuration as the administrator and, if not restricted to the administrator, the user, to enable and disable any developer mode. The evaluator shall test that developer mode access is not available when its configuration is disabled. The evaluator shall verify the developer mode remains disabled during device reboot.

    Function 27 [CONDITIONAL]

    Guidance
    The evaluator shall examine the AGD guidance to determine that it describes how to enable and disable any "Forgot Password", password hint, or remote authentication (to bypass local authentication mechanisms) capability.
    Tests
    For each mechanism listed in the AGD guidance that provides a "Forgot Password" feature or other means where the local authentication process can be bypassed, the evaluator shall disable the feature and ensure that they are not able to bypass the local authentication process.

    Function 28 [CONDITIONAL]

    Tests
    The evaluator shall attempt to wipe Enterprise data resident on the device according to the administrator guidance. The evaluator shall verify that the data is no longer accessible by the user.

    Function 29 [CONDITIONAL]

    TSS
    The evaluator shall verify that the TSS describes how approval for an application to perform the selected action (import, removal) with respect to certificates in the Trust Anchor Database is accomplished (e.g., a pop-up, policy setting, etc.).


    The evaluator shall also verify that the API documentation provided according to Section 5.2.2 Class ADV: Development includes any security functions (import, modification, or destruction of the Trust Anchor Database) allowed by applications.
    Tests
    The evaluator shall perform one of the following tests:
    • Test FMT_SMF.1.1:13: [conditional] If applications may import certificates to the Trust Anchor Database, the evaluator shall write, or the developer shall provide access to, an application that imports a certificate into the Trust Anchor Database. The evaluator shall verify that the TOE requires approval before allowing the application to import the certificate:
      • The evaluator shall deny the approvals to verify that the application is not able to import the certificate. Failure of import shall be tested by attempting to validate a certificate that chains to the certificate whose import was attempted (as described in the evaluation activity for FIA_X509_EXT.1).
      • The evaluator shall repeat the test, allowing the approval to verify that the application is able to import the certificate and that validation occurs.
    • Test FMT_SMF.1.1:14: [conditional] If applications may remove certificates in the Trust Anchor Database, the evaluator shall write, or the developer shall provide access to, an application that removes certificates from the Trust Anchor Database. The evaluator shall verify that the TOE requires approval before allowing the application to remove the certificate:
      • The evaluator shall deny the approvals to verify that the application is not able to remove the certificate. Failure of removal shall be tested by attempting to validate a certificate that chains to the certificate whose removal was attempted (as described in the evaluation activity for FIA_X509_EXT.1).
    The evaluator shall repeat the test, allowing the approval to verify that the application is able to remove/modify the certificate and that validation no longer occurs.

    Function 30 [CONDITIONAL]

    Tests
    The test of this function is performed in conjunction with FIA_X509_EXT.2.2.

    Function 31 [CONDITIONAL]

    TSS
    The evaluator shall ensure that the TSS describes which cellular protocols can be disabled.
    Guidance
    The evaluator shall confirm that the AGD guidance describes the procedure for disabling each cellular protocol identified in the TSS.
    Tests
    The evaluator shall attempt to disable each cellular protocol according to the administrator guidance. The evaluator shall attempt to connect the device to a cellular network and, using network analysis tools, verify that the device does not allow negotiation of the disabled protocols.

    Function 32 [CONDITIONAL]

    Tests
    The evaluator shall attempt to read any device audit logs according to the administrator guidance and verify that the logs may be read. This test may be performed in conjunction with the evaluation activity of FAU_GEN.1.

    Function 33 [CONDITIONAL]

    Tests
    The test of this function is performed in conjunction with FPT_TUD_EXT.5.1.

    Function 34 [CONDITIONAL]

    TSS
    The evaluator shall verify that the TSS describes how the approval for exceptions for shared use of keys or secrets by multiple applications is accomplished (e.g., a pop-up, policy setting, etc.).
    Tests
    The test of this function is performed in conjunction with FCS_STG_EXT.1.

    Function 35 [CONDITIONAL]

    TSS
    The evaluator shall verify that the TSS describes how the approval for exceptions for destruction of keys or secrets by applications that did not import the key or secret is accomplished (e.g., a pop-up, policy setting, etc.).
    Tests
    The test of this function is performed in conjunction with FCS_STG_EXT.1.

    Function 36

    TSS
    The evaluator shall verify that the TSS describes any restrictions in banner settings (e.g., character limitations).
    Tests
    The test of this function is performed in conjunction with FTA_TAB.1.

    Function 37 [CONDITIONAL]

    Tests
    The test of this function is performed in conjunction with FAU_SEL.1.

    Function 38 [CONDITIONAL]

    Tests
    The test of this function is performed in conjunction with FPT_NOT_EXT.2.1.

    Function 39 [CONDITIONAL]

    TSS
    The evaluator shall verify that the TSS includes a description of how data transfers can be managed over USB.
    Tests
    The evaluator shall perform the following tests based on the selections made in the table:
    • Test FMT_SMF.1.1:15: [conditional] The evaluator shall disable USB mass storage mode, attach the device to a computer, and verify that the computer cannot mount the TOE as a drive. The evaluator shall reboot the TOE and repeat this test with other supported auxiliary boot modes.
    • Test FMT_SMF.1.1:16: [conditional] The evaluator shall disable USB data transfer without user authentication, attach the device to a computer, and verify that the TOE requires user authentication before the computer can access TOE data. The evaluator shall reboot the TOE and repeat this test with other supported auxiliary boot modes.
    • Test FMT_SMF.1.1:17: [conditional] The evaluator shall disable USB data transfer without connecting system authentication, attach the device to a computer, and verify that the TOE requires connecting system authentication before the computer can access TOE data. The evaluator shall then connect the TOE to another computer and verify that the computer cannot access TOE data. The evaluator shall then connect the TOE to the original computer and verify that the computer can access TOE data.

    Function 40 [CONDITIONAL]

    TSS
    The evaluator shall verify that the TSS includes a description of available backup methods that can be enabled/disabled. If "selected applications" or "selected groups of applications" are selected the TSS shall include which applications of groups of applications backup can be enabled/disabled.
    Tests
    If all applications is selected, the evaluator shall disable each selected backup location in turn and verify that the TOE cannot complete a backup. The evaluator shall then enable each selected backup location in turn and verify that the TOE can perform a backup.


    If selected applications is selected, the evaluator shall disable each selected backup location in turn and verify that for the selected application the TOE prevents backup from occurring. The evaluator shall then enable each selected backup location in turn and verify that for the selected application the TOE can perform a backup.


    If selected groups of applications is selected, the evaluator shall disable each selected backup location in turn and verify that for a group of applications the TOE prevents the backup from occurring. The evaluator shall then enable each selected backup location in turn and verify for the group of application the TOE can perform a backup.


    If configuration data is selected, the evaluator shall disable each selected backup location in turn and verify that the TOE prevents the backup of configuration data from occurring. The evaluator shall then enable each selected backup location in turn and verify that the TOE can perform a backup of configuration data.

    Function 41 [CONDITIONAL]

    TSS
    The evaluator shall verify that the TSS includes a description of Hotspot functionality and USB tethering to include any authentication for these.
    Tests
    The evaluator shall perform the following tests based on the selections in Function 41.
    • Test FMT_SMF.1.1:18: [conditional] The evaluator shall enable hotspot functionality with each of the of the support authentication methods. The evaluator shall connect to the hotspot with another device and verify that the hotspot functionality requires the configured authentication method.
    • Test FMT_SMF.1.1:19: [conditional] The evaluator shall enable USB tethering functionality with each of the of the support authentication methods. The evaluator shall connect to the TOE over USB with another device and verify that the tethering functionality requires the configured authentication method.

    Function 42 [CONDITIONAL]

    Tests
    The test of this function is performed in conjunction with FDP_ACF_EXT.1.2.

    Function 43 [CONDITIONAL]

    Tests
    The evaluator shall set a policy to cause a designated application to be placed into a particular application group. The evaluator shall then install the designated application and verify that it was placed into the correct group.

    Function 44 [CONDITIONAL]

    Tests
    The evaluator shall attempt to unenroll the device from management and verify that the steps described in FMT_SMF_EXT.2.1 are performed. This test should be performed in conjunction with the FMT_SMF_EXT.2.1 evaluation activity.

    Function 45 [CONDITIONAL]

    TSS
    The evaluator shall verify that the TSS contains guidance to configure the VPN as Always-On.
    Tests
    The evaluator shall configure the VPN as Always-On and perform the following tests:
    • Test FMT_SMF.1.1:20: The evaluator shall verify that when the VPN is connected all traffic is routed through the VPN. This test is performed in conjunction with FDP_IFC_EXT.1.1.
    • Test FMT_SMF.1.1:21: The evaluator shall verify that when the VPN is not established, that no traffic leaves the device. The evaluator shall ensure that the TOE has network connectivity and that the VPN is established. The evaluator shall use a packet sniffing tool to capture the traffic leaving the TOE. The evaluator shall disable the VPN connection on the server side. The evaluator shall perform actions with the device such as navigating to websites, using provided applications, and accessing other Internet resources and verify that no traffic leaves the device.
    • Test FMT_SMF.1.1:22: The evaluator shall verify that the TOE has network connectivity and that the VPN is established. The evaluator shall disable network connectivity (i.e. Airplane Mode) and verify that the VPN disconnects. The evaluator shall re-establish network connectivity and verify that the VPN automatically reconnects.

    Function 46 [CONDITIONAL]

    TSS
    The evaluator shall verify that the TSS describes the procedure to revoke a biometric credential stored on the TOE.
    Tests
    The evaluator shall configure the TOE to use BAF and confirm that the biometric can be used to authenticate to the device. The evaluator shall revoke the biometric credential’s ability to authenticate to the TOE and confirm that the same BAF cannot be used to authenticate to the device.

    Function 47 [CONDITIONAL]

    TSS
    The evaluator shall verify that the TSS describes all assigned security management functions and their intended behavior.
    Tests
    The evaluator shall design and perform tests to demonstrate that the function may be configured and that the intended behavior of the function is enacted by the TOE.

    FMT_SMF_EXT.2 Specification of Remediation Actions

    The TSF shall offer[selection: wipe of protected data, wipe of sensitive data, remove Enterprise applications, remove all device-stored Enterprise resource data, remove Enterprise secondary authentication data, [assignment: list other available remediation actions ]]upon unenrollment and[selection: [assignment: other administrator-configured triggers ], no other triggers].
    Application Note: Unenrollment may consist of removing the MDM agent or removing the administrator’s policies. The functions in the selection are remediation actions that TOE may provide (perhaps via APIs) to the administrator (perhaps via an MDM agent) that may be performed upon unenrollment. "Enterprise applications" refers to applications that are in the Enterprise application group. "Enterprise resource data" refers to all stored Enterprise data and the separate resources that are available to the Enterprise application group, per FDP_ACF_EXT.2.1. If FDP_ACF_EXT.2.1 is included in the ST, then "remove all device-stored Enterprise resource data" must be selected, and is defined to be all resources selected in FDP_ACF_EXT.2.1. If FIA_UAU_EXT.4.1 is included in the ST, then "remove Enterprise secondary authentication data" must be selected. If FIA_UAU_EXT.4.1 is not included in the ST, then "remove Enterprise secondary authentication data" cannot be selected. Enterprise secondary authentication data only refers to any data stored on the TOE that is specifically used as part of a secondary authentication mechanism to authenticate access to Enterprise applications and shared resources. Material that is used for the TOE’s primary authentication mechanism or other purposes not related to authentication to or protection of Enterprise applications or shared resources should not be removed.


    Protected data is all non-TSF data, including all user or enterprise data. Some or all of this data may be considered sensitive data as well. If wipe of protected data is selected it is assumed that the sensitive data is wiped as well. However, if wipe of sensitive data is selected, it does not imply that all non-TSF data (protected data) is wiped. If wipe of protected data or wipe of sensitive data is selected the wipe must be in accordance with FCS_CKM_EXT.5.1. Thus cryptographically wiping the device is an acceptable remediation action.
    TSS
    The evaluator shall verify that the TSS describes all available remediation actions, when they are available for use, and any other administrator-configured triggers. The evaluator shall verify that the TSS describes how the remediation actions are provided to the administrator.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    The evaluator shall use the test environment to iteratively configure the device to perform each remediation action in the selection. The evaluator shall configure the remediation action per how the TSS states it is provided to the administrator. The test environment could be a MDM agent application, but can also be an application with administrator access.

    5.1.7 Class: Protection of the TSF (FPT)

    FPT_AEX_EXT.1 Application Address Space Layout Randomization

    The TSF shall provide address space layout randomization ASLR to applications.
    The base address of any user-space memory mapping will consist of at least 8 unpredictable bits.
    Application Note: The 8 unpredictable bits may be provided by the TSF RBG (as specified in FCS_RBG_EXT.1) but is not required.
    TSS
    The evaluator shall ensure that the TSS section of the ST describes how the 8 bits are generated and provides a justification as to why those bits are unpredictable.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    • Test FPT_AEX_EXT.1.2:1: The evaluator must select 3 apps included with the TSF. These must include any web browser or mail client included with the TSF. For each of these apps, the evaluator shall launch the same app on two separate Mobile Devices of the same type and compare all memory mapping locations. The evaluator must ensure that no memory mappings are placed in the same location on both devices.


      If the rare (at most 1/256) chance occurs that two mappings are the same for a single app and not the same for the other two apps, the evaluator shall repeat the test with that app to verify that in the second test the mappings are different.

    FPT_AEX_EXT.2 Memory Page Permissions

    The TSF shall be able to enforce read, write, and execute permissions on every page of physical memory.
    TSS
    The evaluator shall ensure that the TSS describes of the memory management unit (MMU), and ensures that this description documents the ability of the MMU to enforce read, write, and execute permissions on all pages of virtual memory.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    FPT_AEX_EXT.3 Stack Overflow Protection

    TSF processes that execute in a non-privileged execution domain on the application processor shall implement stack-based buffer overflow protection.
    Application Note: A "non-privileged execution domain" refers to the user mode (as opposed to kernel mode, for instance) of the processor. While not all TSF processes must implement such protection, it is expected that most of the processes (to include libraries used by TSF processes) do implement buffer overflow protections.
    TSS
    The evaluator shall determine that the TSS contains a description of stack-based buffer overflow protections implemented in the TSF software which runs in the non-privileged execution mode of the application processor. The exact implementation of stack-based buffer overflow protection will vary by platform. Example implementations may be activated through compiler options such as "-fstack-protector-all", "-fstack-protector", and "/GS" flags. The evaluator shall ensure that the TSS contains an inventory of TSF binaries and libraries, indicating those that implement stack-based buffer overflow protections as well as those that do not. The TSS must provide a rationale for those binaries and libraries that are not protected in this manner.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    FPT_AEX_EXT.4 Domain Isolation

    The TSF shall protect itself from modification by untrusted subjects.
    The TSF shall enforce isolation of address space between applications.
    Application Note: In addition to the TSF software (e.g., kernel image, device drivers, trusted applications) that resides in storage, the execution context (e.g., address space, processor registers, per-process environment variables) of the software operating in a privileged mode of the processor (e.g., kernel), as well as the context of the trusted applications is to be protected. In addition to the software, any configuration information that controls or influences the behavior of the TSF is also to be protected from modification by untrusted subjects.


    Configuration information includes, but is not limited to, user and administrative management function settings, WLAN profiles, and Bluetooth data such as the service-level security requirements database.


    Untrusted subjects include untrusted applications; unauthorized users who have access to the device while powered off, in a screen-locked state, or when booted into auxiliary boot modes; and, unauthorized users or untrusted software or hardware which may have access to the device over a wired interface, either when the device is in a screen-locked state or booted into auxiliary boot modes.
    TSS
    The evaluator shall ensure that the TSS describes the mechanisms that are in place that prevents non-TSF software from modifying the TSF software or TSF data that governs the behavior of the TSF. These mechanisms could range from hardware-based means (e.g. "execution rings" and memory management functionality); to software-based means (e.g. boundary checking of inputs to APIs). The evaluator determines that the described mechanisms appear reasonable to protect the TSF from modification.


    The evaluator shall ensure the TSS describes how the TSF ensures that the address spaces of applications are kept separate from one another.


    The evaluator shall ensure the TSS details the USSD and MMI codes available from the dialer at the locked state or during auxiliary boot modes that may alter the behavior of the TSF. The evaluator shall ensure that this description includes the code, the action performed by the TSF, and a justification that the actions performed do not modify user or TSF data. If no USSD or MMI codes are available, the evaluator shall ensure that the TSS provides a description of the method by which actions prescribed by these codes are prevented.


    The evaluator shall ensure the TSS documents any TSF data (including software, execution context, configuration information, and audit logs) which may be accessed and modified over a wired interface in auxiliary boot modes. The evaluator shall ensure that the description includes data, which is modified in support of update or restore of the device. The evaluator shall ensure that this documentation includes the auxiliary boot modes in which the data may be modified, the methods for entering the auxiliary boot modes, the location of the data, the manner in which data may be modified, the data format and packaging necessary to support modification, and software or hardware tools, if any, which are necessary for modifying the data.


    The evaluator shall ensure that the TSS provides a description of the means by which unauthorized and undetected modification (that is, excluding cryptographically verified updates per FPT_TUD_EXT.2) of the TSF data over the wired interface in auxiliary boots modes is prevented. The lack of publicly available tools is not sufficient justification. Examples of sufficient justification include auditing of changes, cryptographic verification in the form of a digital signature or hash, disabling the auxiliary boot modes, and access control mechanisms that prevent writing to files or flashing partitions.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    • Test FPT_AEX_EXT.4.2:1: The evaluator shall create and load an app onto the Mobile Device. This app shall attempt to traverse over all file systems and report any locations to which data can be written or overwritten. The evaluator must ensure that none of these locations are part of the OS software, device drivers, system and security configuration files, key material, or another untrusted application’s image/data. For example, it is acceptable for a trusted photo editor app to have access to the data created by the camera app, but a calculator application shall not have access to the pictures.
    • Test FPT_AEX_EXT.4.2:2: For each available auxiliary boot mode, the evaluator shall attempt to modify a TSF file of their choosing using the software or hardware tools described in the TSS. The evaluator shall verify that the modification fails.

    FPT_JTA_EXT.1 JTAG Disablement

    The TSF shall[selection: disable access through hardware, control access by a signing key]to JTAG.
    Application Note: This requirement means that access to JTAG must be disabled either through hardware or restricted through the use of a signing key.
    TSS
    If disable access through hardware is selected:

    The evaluator shall examine the TSS to determine the location of the JTAG ports on the TSF, to include the order of the ports (i.e. Data In, Data Out, Clock, etc.).


    If control access by a signing key is selected:

    The evaluator shall examine the TSS to determine how access to the JTAG is controlled by a signing key. The evaluator shall examine the TSS to determine when the JTAG can be accessed, i.e. what has the access to the signing key.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    Evaluation Activity Note: The following test requires the developer to provide access to a test platform that provides the evaluator with chip level access.


    If disable access through hardware is selected:

    The evaluator shall connect a packet analyzer to the JTAG ports. The evaluator shall query the JTAG port for its device ID and confirm that the device ID cannot be retrieved.


    FPT_KST_EXT.1 Key Storage

    The TSF shall not store any plaintext key material in readable non-volatile memory.
    Application Note: The intention of this requirement is that the TOE will not write plaintext keying material to persistent storage. For the purposes of this requirement, keying material refers to authentication data, passwords, secret/private symmetric keys, private asymmetric keys, data used to derive keys, etc. These values must be stored encrypted.


    This requirement also applies to any value derived from passwords. Thus, the TOE cannot store plaintext password hashes for comparison purposes before protected data is decrypted, and the TOE should use key derivation and decryption to verify the Password Authentication Factor.


    If hybrid is selected in FIA_UAU.5.1 keying material also refers to the PIN/password used as part of the hybrid authentication.
    TSS
    The evaluator shall consult the TSS section of the ST in performing the Evaluation Activities for this requirement.


    In performing their review, the evaluator shall determine that the TSS contains a description of the activities that happen on power-up and password authentication relating to the decryption of DEKs, stored keys, and data.


    The evaluator shall ensure that the description also covers how the cryptographic functions in the FCS requirements are being used to perform the encryption functions, including how the KEKs, DEKs, and stored keys are unwrapped, saved, and used by the TOE so as to prevent plaintext from being written to non-volatile storage. The evaluator shall ensure that the TSS describes, for each power-down scenario how the TOE ensures that all keys in non-volatile storage are not stored in plaintext.


    The evaluator shall ensure that the TSS describes how other functions available in the system (e.g., regeneration of the keys) ensure that no unencrypted key material is present in persistent storage.


    The evaluator shall review the TSS to determine that it makes a case that key material is not written unencrypted to the persistent storage.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    FPT_KST_EXT.2 No Key Transmission

    The TSF shall not transmit any plaintext key material outside the security boundary of the TOE.
    Application Note: The intention of this requirement is to prevent the logging of plaintext key information to a service that transmits the information off-device. For the purposes of this requirement, key material refers to keys, passwords, and other material that is used to derive keys.


    If hybrid is selected in FIA_UAU.5.1 keying material also refers to the PIN/password used as part of the hybrid authentication.


    In the future, this requirement will apply to symmetric and asymmetric private keys stored in the TOE secure key storage where applications are outside the boundary of the TOE. Thus, the TSF will be required to provide cryptographic key operations (signature, encryption, and decryption) on behalf of applications (FCS_SRV_EXT.2.1) that have access to those keys.
    TSS
    The evaluator shall consult the TSS section of the ST in performing the Evaluation Activities for this requirement. The evaluator shall ensure that the TSS describes the TOE security boundary. The cryptographic module may very well be a particular kernel module, the Operating System, the Application Processor, or up to the entire Mobile Device.


    In performing their review, the evaluator shall determine that the TSS contains a description of the activities that happen on power-up and password authentication relating to the decryption of DEKs, stored keys, and data.


    The evaluator shall ensure that the TSS describes how other functions available in the system (e.g., regeneration of the keys) ensure that no unencrypted key material is transmitted outside the security boundary of the TOE.


    The evaluator shall review the TSS to determine that it makes a case that key material is not transmitted outside the security boundary of the TOE.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    FPT_KST_EXT.3 No Plaintext Key Export

    The TSF shall ensure it is not possible for the TOE users to export plaintext keys.
    Application Note: Plaintext keys include DEKs, KEKs, and all keys stored in the secure key storage (FCS_STG_EXT.1). The intent of this requirement is to prevent the plaintext keys from being exported during a backup authorized by the TOE user or administrator.
    TSS
    The ST author will provide a statement of their policy for handling and protecting keys. The evaluator shall check to ensure the TSS describes a policy in line with not exporting either plaintext DEKs, KEKs, or keys stored in the secure key storage.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    FPT_NOT_EXT.1 Self-Test Notification

    The TSF shall transition to non-operational mode and[selection: log failures in the audit record, notify the administrator, [assignment: other actions ], no other actions]when the following types of failures occur:
    • failures of the self-tests
    • TSF software integrity verification failures
    • [selection: no other failures, [assignment: other failures ]]
    TSS
    The evaluator shall verify that the TSS describes critical failures that may occur and the actions to be taken upon these critical failures.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
      The following test require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products.
    • Test FPT_NOT_EXT.1.1:1: The evaluator shall use a tool provided by the developer to modify files and processes in the system that correspond to critical failures specified in the second list. The evaluator shall verify that creating these critical failures causes the device to take the remediation actions specified in the first list.

    FPT_STM.1 Reliable Time Stamps

    The TSF shall be able to provide reliable time stamps for its own use .
    TSS
    The evaluator shall examine the TSS to ensure that it lists each security function that makes use of time. The TSS provides a description of how the time is maintained and considered reliable in the context of each of the time related functions. This documentation must identify whether the TSF uses a NTP server or the carrier’s network time as the primary time sources.


    Guidance
    The evaluator examines the operational guidance to ensure it describes how to set the time.


    Tests
    • Test FPT_STM.1.1:1: The evaluator uses the operational guide to set the time. The evaluator shall then use an available interface to observe that the time was set correctly.

    FPT_TST_EXT.1 TSF Cryptographic Functionality Testing

    The TSF shall run a suite of self-tests during initial start-up (on power on) to demonstrate the correct operation of all cryptographic functionality.
    Application Note: This requirement may be met by performing known answer tests or pair-wise consistency tests. The self-tests must be performed before the cryptographic functionality is exercised (for example, during the initialization of a process that utilizes the functionality).


    The cryptographic functionality includes the cryptographic operations in FCS_COP, the key generation functions in FCS_CKM, and the random bit generation in FCS_RBG_EXT.
    TSS
    The evaluator shall examine the TSS to ensure that it specifies the self-tests that are performed at start-up. This description must include an outline of the test procedures conducted by the TSF (e.g., rather than saying "memory is tested", a description similar to "memory is tested by writing a value to each memory location and reading it back to ensure it is identical to what was written" shall be used). The TSS must include any error states that they TSF may enter when self-tests fail, and the conditions and actions necessary to exit the error states and resume normal operation. The evaluator shall verify that the TSS indicates these self-tests are run at start-up automatically, and do not involve any inputs from or actions by the user or operator.


    The evaluator shall inspect the list of self-tests in the TSS and verify that it includes algorithm self-tests. The algorithm self-tests will typically be conducted using known answer tests.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    FPT_TST_EXT.2 TSF Integrity Checking

    The TSF shall verify the integrity of[assignment: TSF data]stored in mutable media prior to its execution through the use of[assignment: cryptographic or immutable hardware mechanism].

    FPT_TST_EXT.2/PREKERNEL TSF Integrity Checking (Pre-Kernel)

    The TSF shall verify the integrity of [ the bootchain up through the Application Processor OS kernel ] stored in mutable media prior to its execution through the use of[selection: a digital signature using an immutable hardware asymmetric key, an immutable hardware hash of an asymmetric key, an immutable hardware hash, a digital signature using a hardware-protected asymmetric key].
    Application Note: The bootchain of the TSF is the sequence of firmware and software, including ROM, bootloaders, and kernel, which ultimately result in loading the kernel on the Application Processor, regardless of which processor executes that code. Executable code that would be loaded after the kernel is covered in FPT_TST_EXT.2/POSTKERNEL.


    In order to meet this requirement, the hardware protection may be transitive in nature: a hardware-protected public key, hash of an asymmetric key, or hash may be used to verify the mutable bootloader code which contains a key or hash used by the bootloader to verify the mutable OS kernel code, which contains a key or hash to verify the next layer of executable code, and so on.


    The cryptographic mechanism used to verify the (initial) mutable executable code must be protected, such as being implemented in hardware or in read-only memory (ROM).
    TSS
    The evaluator shall verify that the TSS section of the ST includes a description of the boot procedures, including a description of the entire bootchain, of the software for the TSF’s Application Processor. The evaluator shall ensure that before loading the bootloaders for the operating system and the kernel, all bootloaders and the kernel software itself is cryptographically verified. For each additional category of executable code verified before execution, the evaluator shall verify that the description in the TSS describes how that software is cryptographically verified.


    The evaluator shall verify that the TSS contains a justification for the protection of the cryptographic key or hash, preventing it from being modified by unverified or unauthenticated software. The evaluator shall verify that the TSS contains a description of the protection afforded to the mechanism performing the cryptographic verification.


    The evaluator shall verify that the TSS describes each auxiliary boot mode available on the TOE during the boot procedures. The evaluator shall verify that, for each auxiliary boot mode, a description of the cryptographic integrity of the executed code through the kernel is verified before each execution.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
      The evaluator shall perform the following tests:
    • Test FPT_TST_EXT.2.1/PREKERNEL:1: The evaluator shall perform actions to cause TSF software to load and observe that the integrity mechanism does not flag any executables as containing integrity errors and that the TOE properly boots.
    • Test FPT_TST_EXT.2.1/PREKERNEL:2: The evaluator shall modify a TSF executable that is integrity protected and cause that executable to be successfully loaded by the TSF. The evaluator observes that an integrity violation is triggered and the TOE does not boot. (Care must be taken so that the integrity violation is determined to be the cause of the failure to load the module, and not the fact that the module was modified so that it was rendered unable to run because its format was corrupt).
    • Test FPT_TST_EXT.2.1/PREKERNEL:3: [conditional] If the ST author indicates that the integrity verification is performed using a public key, the evaluator shall verify that the update mechanism includes a certificate validation according to FIA_X509_EXT.1. The evaluator shall digitally sign the TSF executable with a certificate that does not have the Code Signing purpose in the extendedKeyUsage field and verify that an integrity violation is triggered. The evaluator shall repeat the test using a certificate that contains the Code Signing purpose and verify that the integrity verification succeeds. Ideally, the two certificates should be identical except for the extendedKeyUsage field.

    FPT_TUD_EXT.1 TSF Version Query

    The TSF shall provide authorized users the ability to query the current version of the TOE firmware/software.
    The TSF shall provide authorized users the ability to query the current version of the hardware model of the device.
    Application Note: The current version of the hardware model of the device is an identifier that is sufficient to indicate (in tandem with manufacturer documentation) the hardware which comprises the device.
    The TSF shall provide authorized users the ability to query the current version of installed mobile applications.
    Application Note: The current version of mobile applications is the name and published version number of each installed mobile application.
    The evaluator shall establish a test environment consisting of the Mobile Device and any supporting software that demonstrates usage of the management functions. This can be test software from the developer, a reference implementation of management software from the developer, or other commercially available software. The evaluator shall set up the Mobile Device and the other software to exercise the management functions according to the provided guidance documentation.
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    • Test FPT_TUD_EXT.1.3:1: Using the AGD guidance provided, the evaluator shall test that the administrator and user can query:
      • The current version of the TSF operating system and any firmware that can be updated separately
      • The hardware model of the TSF
      • The current version of all installed mobile applications

    FPT_TUD_EXT.2 TSF Update Verification

    The TSF shall verify software updates to the Application Processor system software and[selection: [assignment: other processor system software ], no other processor system software]using a digital signature verified by the manufacturer trusted key prior to installing those updates.
    Application Note: The digital signature mechanism is implemented in accordance with FCS_COP.1.1/SIGN.


    At this time, this requirement does not require verification of software updates to the software operating outside the Application Processor.


    Any change, via a supported mechanism, to software residing in non-volatile storage is deemed a software update. Thus, this requirement applies to TSF software updates regardless of how the software arrives or is delivered to the device. This includes over-the-air (OTA) updates as well as partition images containing software which may be delivered to the device over a wired interface.
    The TSF shall[selection: never update, update only by verified software]the TSF boot integrity[selection: key, hash].
    Application Note: The key or hash updated via this requirement is used for verifying software before execution in FPT_TST_EXT.2/PREKERNEL. The key or hash is verified as a part of the digital signature on an update, and the software which performs the update of the key or hash is verified by FPT_TST_EXT.2/PREKERNEL.
    The TSF shall verify that the digital signature verification key used for TSF updates[selection: is validated to a public key in the Trust Anchor Database, matches an immutable hardware public key].
    Application Note: The ST author must indicate the method by which the signing key for system software updates is limited and, if selected in FPT_TUD_EXT.2.3, must indicate how this signing key is protected by the hardware.


    If certificates are used, certificates are validated for the purpose of software updates in accordance with FIA_X509_EXT.1 and should be selected in FIA_X509_EXT.2.1. Additionally, FPT_TUD_EXT.4 must be included in the ST.
    TSS
    The evaluator shall verify that the TSS section of the ST describes all TSF software update mechanisms for updating the system software. The evaluator shall verify that the description includes a digital signature verification of the software before installation and that installation fails if the verification fails. The evaluator shall verify that all software and firmware involved in updating the TSF is described and, if multiple stages and software are indicated, that the software/firmware responsible for each stage is indicated and that the stages which perform signature verification of the update are identified.


    The evaluator shall verify that the TSS describes the method by which the digital signature is verified and that the public key used to verify the signature is either hardware-protected or is validated to chain to a public key in the Trust Anchor Database. If hardware-protection is selected, the evaluator shall verify that the method of hardware-protection is described and that the ST author has justified why the public key may not be modified by unauthorized parties.


    [conditional] If the ST author indicates that software updates to system software running on other processors is verified, the evaluator shall verify that these other processors are listed in the TSS and that the description includes the software update mechanism for these processors, if different than the update mechanism for the software executing on the Application Processor.


    [conditional] If the ST author indicates that the public key is used for software update digital signature verification, the evaluator shall verify that the update mechanism includes a certificate validation according to FIA_X509_EXT.1 and a check for the Code Signing purpose in the extendedKeyUsage.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
      The evaluator shall verify that the developer has provided evidence that the following tests were performed for each available update mechanism:
    • Test FPT_TUD_EXT.2.3:1: The tester shall try to install an update without the digital signature and shall verify that installation fails. The tester shall attempt to install an update with digital signature, and verify that installation succeeds.

    • Test FPT_TUD_EXT.2.3:2: The tester shall digitally sign the update with a key disallowed by the device and verify that installation fails. The tester shall attempt to install an update signed with the allowed key and verify that installation succeeds.

    • Test FPT_TUD_EXT.2.3:3: [conditional] The tester shall digitally sign the update with an invalid certificate and verify that update installation fails. The tester attempt to install an update that was digitally signed using a valid certificate and a certificate that contains the purpose and verify that the update installation succeeds.

    • Test FPT_TUD_EXT.2.3:4: [conditional] The tester shall repeat these test for the software executing on each processor listed in the first selection. The tester shall attempt to install an update without the digital signature and shall verify that installation fails. The tester shall attempt to install an update with digital signature, and verify that installation succeeds.

    FPT_TUD_EXT.3 Application Signing

    The TSF shall verify mobile application software using a digital signature mechanism prior to installation.
    Application Note: This requirement does not necessitate an X.509v3 certificate or certificate validation. X.509v3 certificates and certificate validation are addressed in FPT_TUD_EXT.5.1.
    TSS
    The evaluator shall verify that the TSS describes how mobile application software is verified at installation. The evaluator shall ensure that this method uses a digital signature.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    • Test FPT_TUD_EXT.3.1:1: The evaluator shall write, or the developer shall provide access to, an application. The evaluator shall try to install this application without a digitally signature and shall verify that installation fails. The evaluator shall attempt to install a digitally signed application, and verify that installation succeeds.

    5.1.8 Class: TOE Access (FTA)

    FTA_SSL_EXT.1 TSF- and User-initiated Locked State

    The TSF shall transition to a locked state after a time interval of inactivity.
    The TSF shall transition to a locked state after initiation by either the user or the administrator.
    The TSF shall, upon transitioning to the locked state, perform the following operations:
    • Clearing or overwriting display devices, obscuring the previous contents;
    • [assignment: Other actions performed upon transitioning to the locked state].
    Application Note: The time interval of inactivity is configured using FMT_SMF.1 function 2. The user/administrator-initiated lock is specified in FMT_SMF.1 function 6.
    TSS
    The evaluator shall verify the TSS describes the actions performed upon transitioning to the locked state.


    Guidance
    The evaluation shall verify that the AGD guidance describes the method of setting the inactivity interval and of commanding a lock. The evaluator shall verify that the TSS describes the information allowed to be displayed to unauthorized users.


    Tests
    • Test FTA_SSL_EXT.1.3:1: The evaluator shall configure the TSF to transition to the locked state after a time of inactivity (FMT_SMF.1) according to the AGD guidance. The evaluator shall wait until the TSF locks and verify that the display is cleared or overwritten and that the only actions allowed in the locked state are unlocking the session and those actions specified in FIA_UAU_EXT.2.
    • Test FTA_SSL_EXT.1.3:2: The evaluator shall command the TSF to transition to the locked state according to the AGD guidance as both the user and the administrator. The evaluator shall wait until the TSF locks and verify that the display is cleared or overwritten and that the only actions allowed in the locked state are unlocking the session and those actions specified in FIA_UAU_EXT.2.

    FTA_TAB.1 Default TOE Access Banners

    Before establishing a user session, the TSF shall display an advisory warning message regarding unauthorized use of the TOE.
    Application Note: This requirement may be met with the configuration of either text or an image containing the text of the desired message. The TSF must minimally display this information at startup, but may also display the information at every unlock. The banner is configured according to FMT_SMF.1 function 36.
    TSS
    The TSS shall describe when the banner is displayed.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
      The evaluator shall also perform the following test:
    • Test FTA_TAB.1.1:1: The evaluator follows the operational guidance to configure a notice and consent warning message. The evaluator shall then start up or unlock the TSF. The evaluator shall verify that the notice and consent warning message is displayed in each instance described in the TSS.

    5.1.9 Class: Trusted Path/Channels (FTP)

    FTP_ITC_EXT.1 Trusted Channel Communication

    The TSF shall use and[selection: IPsec in accordance with the PP-Module for Virtual Private Network (VPN) Clients, version 2.4, mutually authenticated DTLS as defined in the Functional Package for Transport Layer Security (TLS), version 1.1, HTTPS]protocols to provide a communication channel between itself and another trusted IT product that is logically distinct from other communication channels, provides assured identification of its end points, protects channel data from disclosure, and detects modification of the channel data.
    Application Note: The intent of the mandatory portion of the above requirement is to use the cryptographic protocols identified in the requirement to establish and maintain a trusted channel between the TOE and an access point, VPN Gateway, or other trusted IT product.


    The ST author must list which trusted channel protocols are implemented by the Mobile Device.


    The TSF must be validated against the PP-Module for Wireless LAN Clients, version 1.0 to satisfy the mandatory trusted channels of 802.11-2012, 802.1X, and EAP-TLS.


    To satisfy the mandatory trusted channel of TLS and if mutually authenticated DTLS is selected, the TSF must be validated against the Functional Package for Transport Layer Security (TLS), version 1.1, with the following selections made:
    • FCS_TLS_EXT.1:
      • Either TLS or DTLS is selected as appropriate
      • Client is selected
    • FCS_TLSC_EXT.1.1 or FCS_DTLSC_EXT.1.1 (as appropriate):
      • The cipher suites selected must correspond with the algorithms and hash functions allowed in FCS_COP.1.
      • Mutual authentication must be selected
    • FCS_TLSC_EXT.1.3 or FCS_DTLSC_EXT.1.3 (as appropriate):
      • With no exceptions is selected.

    If the ST author selects IPsec, the TSF must be validated against the PP-Module for Virtual Private Network (VPN) Clients, version 2.4.


    Appendix B - Selection-based Requirements contains the requirements for implementing each of the other optional trusted channel protocols. The ST author must include the security functional requirements for the trusted channel protocol selected in FTP_ITC_EXT.1 in the main body of the ST.


    Assured identification of endpoints is performed according to the authentication mechanisms used by the listed trusted channel protocols.
    Validation Guidelines:

    Rule #10

    Rule #11
    The TSF shall permit the TSF to initiate communication via the trusted channel.
    The TSF shall initiate communication via the trusted channel for wireless access point connections, administrative communication, configured enterprise connections, and[selection: OTA updates, no other connections].
    TSS
    The evaluator shall examine the TSS to determine that it describes the details of the TOE connecting to access points, VPN Gateways, and other trusted IT products in terms of the cryptographic protocols specified in the requirement, along with TOE-specific options or procedures that might not be reflected in the specifications. The evaluator shall also confirm that all protocols listed in the TSS are specified and included in the requirements in the ST.


    If OTA updates are selected, the TSS shall describe which trusted channel protocol is initiated by the TOE and is used for updates.


    Guidance
    The evaluator shall confirm that the operational guidance contains instructions for establishing the connection to access points, VPN Gateways, and other trusted IT products.


    Tests
      The evaluator shall also perform the following tests for each protocol listed:
    • Test FTP_ITC_EXT.1.3:1: The evaluator shall ensure, for each communication channel with an authorized IT entity, the channel data are not sent in plaintext and that a protocol analyzer identifies the traffic as the protocol under testing.
    • Test FTP_ITC_EXT.1.3:2: [conditional] If IPsec is selected, the evaluator shall ensure that the TOE is able to initiate communications with a VPN Gateway, setting up the connections as described in the operational guidance and ensuring that communication is successful.
    • Test FTP_ITC_EXT.1.3:3: [conditional]If OTA updates are selected, the evaluator shall trigger an update request according to the operational guidance and shall ensure that the communication is successful.
    • Test FTP_ITC_EXT.1.3:4: For any other selected protocol (not tested in Test 1, 2, or 3), the evaluator shall ensure that the TOE is able to initiate communications with a trusted IT product using the protocol, setting up the connection as described in the operational guidance and ensuring that the communication is successful.

    5.1.10 TOE Security Functional Requirements Rationale

    The following rationale provides justification for each security objective for the TOE, showing that the SFRs are suitable to meet and achieve the security objectives:
    INTEGRITYFMT_CFG
    Table 2 7: SFR Rationale
    ObjectiveAddressed byRationale
    O.AUTH

    FDPFIA_DECAFL_EXT.1The PP includes FDP_DECFIA_AFL_EXT.1 to limit access to platform hardware resources, which limits the methods by which an attacker can attempt to compromise the integrity of the TOE.
    supports the objective by defining the authentication mechanisms that are subject to lockout behavior and how the TSF handles repeated failed authentication attempts.
    FIA_PMG_EXT.1The PP includes FMT_CFGFIA_PMG_EXT.1 supports the objective by defining the minimum quality threshold for the TSP to limit unauthorized access to itself by preventing the use of default authentication credentials and by ensuring that the TOE uses appropriately restrictive platform permissions on its binaries and data
    FPT_AEX_EXT.1The PP includes FPT_AEX_EXT.1 to add complexity to the task of compromising systems by ensuring that application is compatible with security features provided by the platform vendor and that the application implements platform-provided anti-exploitations such as ASLR and stack overflow protection.
    FPT_TUD_EXT.1The PP includes FPT_TUD_EXT.1 to ensure that the TOE can be patched and that any updates to the TOE have appropriate integrity protection.
    O.QUALITY

    FCS_CKM.1The PP supports this objective by allowing FCS_CKM_EXT.1 to specify that the TSF may rely on platform-provided key generation services.
    FCS_RBG_EXT.1The PP supports this objective by allowing FCS_RBG_EXT.1 to specify that the TSF may rely on platform-provided random bit generation services.
    FCS_STO_EXT.1The PP supports this objective by allowing FCS_STO_EXT.1 to specify that the TSF may rely on platform-provided credential storage services.
    FDP_DAR_EXT.1The PP supports this objective by allowing FDP_DAR_EXT.1 to specify that the TSF may rely on platform-provided data-at-rest protection services.
    FMT_MEC_EXT.1The PP includes FMT_MEC_EXT.1 to ensure that the TOE can use platform services to store and set configuration options.
    FPT_API_EXT.1The PP includes FPT_API_EXT.1 to require the TOE to leverage platform functionality by using only documented and supported APIs.
    FPT_LIB_EXT.1The PP includes FPT_LIB_EXT.1 to ensure that the TOE does not include any unnecessary or unexpected third-party libraries which could present a privacy threat or vulnerability.
    FTP_DIT_EXT.1The PP supports this objective by allowing FTP_DIT_EXT.1 to specify that the TSF may rely on platform-provided services to implement trusted communications.
    FCS_CKM.1/AK (selection-based)The PP supports this objective by allowing FCS_CKM.1/AK to specify that the TSF may rely on platform-provided asymmetric key generation services.
    FCS_CKM.2 (selection-based)The PP supports this objective by allowing FCS_CKM.2 to specify that the TSF may rely on platform-provided key establishment services.
    FIA_X509_EXT.1 (selection-based)The PP supports this objective by allowing FIA_X509_EXT.1 to specify that the TSF may rely on platform-provided X.509 certificate validation services.
    FPT_TUD_EXT.2 (selection-based)The TSF includes FPT_TUD_EXT.2 to specify that the TOE may leverage the platform-supported package manager for application distribution and leverages platform-provided mechanisms to remove all traces of itself when removed from the platform system.
    FPT_API_EXT.2 (objective)The PP includes FPT_API_EXT.2 to permit the TOE to use platform-provided libraries for parsing IANA MIME media formats.
    O.MANAGEMENT

    FMT_SMF.1The PP includes FMT_SMF.1 to define the security-relevant management functions that are supported by the TOE.
    FPR_ANO_EXT.1The PP includes FPR_ANO_EXT.1 to define how the TSF provides control to the user regarding the disclosure of any PII.
    FPT_IDV_EXT.1The PP includes FPT_IDV_EXT.1 to provide a methodology for identifying the TOE versioning.
    FPT_TUD_EXT.1The PP includes FPT_TUD_EXT.1 to define how updates to the TOE are deployed and verified.
    FCS_COP.1/SigThe PP includes FCS_COP.1/Sig to define the mechanism used to verify TOE updates if the TOE implements this functionality rather than the underlying platform.
    O.PROTECTED_STORAGE

    FCS_RBG_EXT.1The PP includes FCS_RBG_EXT.1 to define whether random bit generation services are implemented by the TSF or the platform. Depending on how data at rest is protected, the TOE may rely on the use of a random bit generator to create keys that are subsequently used for data protection.
    FCS_STO_EXT.1The PP includes FCS_STO_EXT.1 to define the mechanism that the TSF uses or relies upon to protect stored credential data.
    FDP_DAR_EXT.1The PP includes FDP_DAR_EXT.1 to define the mechanism that the TSF uses or relies upon to protect sensitive data at rest.
    FCS_CKM.1/SK (optional)The PP includes FCS_CKM.1/SK to define the TOE’s capability to generate symmetric keys. These keys may subsequently be used to encrypt stored credential data based on the claims made in FCS_STO_EXT.1.
    FCS_CKM.1/PBKDF (selection-based)The PP includes FCS_CKM.1/PBKDF to define the password-based key derivation function that may be used to encrypt stored credential data based on the claims made in FCS_STO_EXT.1.
    FCS_COP.1/SKC (selection-based)The PP includes FCS_COP.1/SKC to define the AES cryptographic algorithm that may be used to encrypt stored credential data based on the claims made in FCS_STO_EXT.1.
    FCS_COP.1/Hash (selection-based)The PP includes FCS_COP.1/Hash to define integrity mechanisms that may be used by the TOE as part of ensuring that data at rest is protected.
    FCS_COP.1/KeyedHash (selection-based)The PP includes FCS_COP.1/KeyedHash to define HMAC mechanisms that may be used by the TOE as part of ensuring that data at rest is protected.
    FCS_RBG_EXT.2 (selection-based)The PP includes FCS_RBG_EXT.2 to define the TOE’s implementation of random bit generation functionality in the event that the TOE provides this function in support of generating keys that are used for data protection.
    O.PROTECTED_COMMS

    FCS_RBG_EXT.1The PP includes FCS_RBG_EXT.1 to define whether the random bit generation services used in establishing trusted communications are implemented by the TSF or by the platform.
    FCS_CKM.1The PP includes FCS_CKM_EXT.1 to specify whether the TOE or the platform is responsible for generation of any asymmetric keys that may be used for establishing trusted communications.
    FTP_DIT_EXT.1The PP includes FTP_DIT_EXT.1 to define the trusted channels used to protect data in transit, the data that is protected, and whether the trusted channels are implemented by the TSF or the platform.
    FCS_CKM.1/AKThe PP includes FCS_CKM.1/AK to define whether the TSF or the platform generates asymmetric keys that are used in support of trusted communications.
    FCS_CKM.2The PP includes FCS_CKM.2 to define whether the TSF or the platform performs key establishment for trusted communications.
    FCS_COP.1/SKCThe PP includes FCS_COP.1/SKC to define the symmetric encryption algorithms used in support of trusted communications.
    FCS_COP.1/HashThe PP includes FCS_COP.1/Hash to define the hash algorithms used in support of trusted communications.
    FCS_COP.1/SigThe PP includes FCS_COP.1/Sig to define the digital signature algorithms used in support of trusted communications.
    FCS_COP.1/KeyedHashThe PP includes FCS_COP.1/KeyedHash to define the HMAC algorithms used in support of trusted communications.
    FCS_RBG_EXT.2The PP includes FCS_RBG_EXT.2 to define the DRBG algorithms used in support of trusted communications.
    FCS_HTTPS_EXT.1/ClientThe PP includes FCS_HTTPS_EXT.1 to define the TOE’s support for the HTTPS trusted communications protocol as a client.
    FCS_HTTPS_EXT.1/ServerThe PP includes FCS_HTTPS_EXT.1 to define the TOE’s support for the HTTPS trusted communications protocol as a server.
    FDP_NET_EXT.1The PP includes FDP_NET_EXT.1 to define the TOE’s usage of network communications, which may include the transmission or receipt of data over a trusted channel.
    FIA_X509_EXT.1The PP includes FIA_X509_EXT.1 to define X.509 certificate validation activities in support of trusted communications.
    FIA_X509_EXT.2The PP includes FIA_X509_EXT.2 to define the trusted communications that X.509 certificate services support, as well as the extent to which trusted communications can be established when using a certificate with unknown validitypasswords that the TSF must enforce.
    FIA_TRT_EXT.1FIA_TRT_EXT.1 supports the objective by enforcing an authentication throttling mechanism that limits the rate at which authentication attempts can be made to the TOE.
    FIA_UAU.5FIA_UAU.5 supports the objective by defining all authentication factors the TSF supports and rules for how these authentication factors are used to gain access to the TSF.
    FIA_UAU.6/CREDENTIALFIA_UAU.6/CREDENTIAL supports the objective by requiring the TSF to re-authenticate users with their password prior to allowing them to change any other authentication data.
    FIA_UAU.6/LOCKEDFIA_UAU.6/LOCKED supports the objective by requiring the TSF to re-authenticate users with a valid credential prior to allowing a locked device to be unlocked.
    FIA_UAU.7FIA_UAU.7 supports the objective by ensuring that TSF does not disclose user authentication data as it is being input to the TOE.
    FIA_UAU_EXT.1FIA_UAU_EXT.1 supports the objective by requiring the TSF to be provided with a valid password before access to protected data is granted.
    FIA_UAU_EXT.2FIA_UAU_EXT.2 supports the objective by defining the TOE functions that can be accessed without authentication such that all other services require authentication.
    FIA_UAU_EXT.4FIA_UAU_EXT.4 supports the objective by defining a secondary authentication mechanism for Enterprise resources.
    FIA_X509_EXT.2FIA_X509_EXT.2 supports the objective by defining the functions for which the TSF uses X.509 certificates as an authentication mechanism.
    FTA_SSL_EXT.1FTA_SSL_EXT.1 supports the objective by requiring the TSF to ensure that an idle user session is terminated after a given period of time.
    O.CONFIG

    FMT_MOF_EXT.1FMT_MOF_EXT.1 supports the objective by specifying the TSF management functions that an end user is authorized to perform.
    FMT_SMF.1FMT_SMF.1 supports the objective by defining the TSF management functions and the users or roles that are authorized to invoke them.
    FMT_SMF_EXT.2FMT_SMF_EXT.2 supports the objective by defining the configuration actions that the TSF performs automatically upon unenrollment from mobile device management.
    FTA_TAB.1FTA_TAB.1 supports the objective by requiring the TSF to display a warning banner to users that governs authorized usage of the TOE.
    O.INTEGRITY

    FAU_GEN.1FAU_GEN.1 supports the objective by requiring the TSF to record actions performed against it to establish a record of potential malicious activity.
    FAU_SAR.1FAU_SAR.1 supports the objective by requiring the TSF to provide a mechanism to review the stored audit data so administrators can diagnose the root cause of malicious usage.
    FAU_SEL.1FAU_SEL.1 supports the objective by allowing the TSF to restrict the audit records that are generated so that records unrelated to potential malicious usage can be suppressed.
    FAU_STG.1FAU_STG.1 supports the objective by ensuring that a malicious user cannot tamper with audit records by modifying or deleting them.
    FAU_STG.4FAU_STG.4 supports the objective by ensuring the availability of audit records.
    FCS_COP.1/HASHFCS_COP.1/HASH supports the objective by requiring the TSF to implement hash algorithms that can be used to assert and verify integrity.
    FCS_COP.1/SIGNFCS_COP.1/SIGN supports the objective by requiring the TSF to implement digital signature algorithms that can be used to assert and verify integrity.
    FDP_ACF_EXT.1FDP_ACF_EXT.1 supports the objective by requiring the TSF to maintain the integrity of its system services by limiting the entities that can access them.
    FDP_ACF_EXT.3FDP_ACF_EXT.3 supports the objective by requiring the TSF to ensure that writable files cannot be executed and vice versa, such that arbitrary code or scripts cannot be executed to compromise the integrity of the TOE.
    FPT_AEX_EXT.1FPT_AEX_EXT.1 supports the objective by requiring the TSF to implement ASLR to prevent a compromise of the TSF.
    FPT_AEX_EXT.2FPT_AEX_EXT.2 supports the objective by requiring the TSF to enforce permissions against memory pages to prevent a compromise of the TSF.
    FPT_AEX_EXT.3FPT_AEX_EXT.3 supports the objective by requiring the TSF to implement stack overflow protection to prevent a compromise of the TSF.
    FPT_AEX_EXT.4FPT_AEX_EXT.4 supports the objective by requiring the TSF to enforce address space separation to prevent a compromise of the TSF.
    FPT_AEX_EXT.5FPT_AEX_EXT.5 supports the objective by requiring the TSF to implement ASLR to prevent a compromise of the TSF.
    FPT_AEX_EXT.6FPT_AEX_EXT.6 supports the objective by requiring the TSF to ensure that writable files cannot be executed and vice versa, such that arbitrary code or scripts cannot be executed to compromise the integrity of the TOE.
    FPT_AEX_EXT.7FPT_AEX_EXT.7 supports the objective by requiring the TSF to implement heap overflow protection to prevent a compromise of the TSF.
    FPT_BBD_EXT.1FPT_BBD_EXT.1 supports the objective by ensuring that isolation between the TOE's baseband processor and application processor is enforced so that access to the baseband processor is strictly controlled.
    FPT_NOT_EXT.1FPT_NOT_EXT.1 supports the objective by requiring the TSF to take some action to prevent its integrity in the event of various failure conditions.
    FPT_NOT_EXT.2FPT_NOT_EXT.2 supports the objective by requiring the TSF to make its integrity verification values available for the purpose of remote attestation.
    FPT_STM.1FPT_STM.1 supports the objective by ensuring accurate system time data is applied to audit logs.
    FPT_TST_EXT.1FPT_TST_EXT.1 supports the objective by defining the self-tests that the TSF performs to validate its own integrity.
    FPT_TST_EXT.2/POSTKERNELFPT_TST_EXT.2/POSTKERNEL supports the objective by requiring the TSF to verify the integrity of stored executable code prior to its execution.
    FPT_TST_EXT.2/PREKERNELFPT_TST_EXT.2/PREKERNEL supports the objective by requiring the TSF to verify the integrity of its bootchain prior to kernel load.
    FPT_TST_EXT.3FPT_TST_EXT.3 supports the objective by requiring the TSF to block code execution if its code signing certificate is invalid.
    FPT_TUD_EXT.1FPT_TUD_EXT.1 supports the objective by allowing users to determine the version of the TOE's hardware, software/firmware, and installed applications.
    FPT_TUD_EXT.2FPT_TUD_EXT.2 supports the objective by requiring the TSF to validate the integrity of software updates prior to installing them.
    FPT_TUD_EXT.3FPT_TUD_EXT.3 supports the objective by requiring the TSF to validate the integrity of third-party applications prior to installing them.
    FPT_TUD_EXT.4FPT_TUD_EXT.4 supports the objective by requiring the TSF to block installation of code if its associated code signing certificate is invalid.
    FPT_TUD_EXT.5FPT_TUD_EXT.5 supports the objective by specifying the X.509 certificate that the TSF uses to verify applications prior to their installation.
    FPT_TUD_EXT.6FPT_TUD_EXT.6 supports the objective by preventing the TSF from being rolled back to an earlier version that may have known vulnerabilities that were subsequently patched.
    O.PRIVACY

    FDP_ACF_EXT.1FDP_ACF_EXT.1 supports the objective by enforcing restrictions on services that could compromise user privacy if accessed inappropriately.
    FDP_ACF_EXT.2FDP_ACF_EXT.2 supports the objective by requiring the TSF to provide separate user data stores for application groups so that the privacy of that data can be maintained.
    FDP_BCK_EXT.1FDP_BCK_EXT.1 supports the objective by allowing data to be excluded from backup operations that could compromise user privacy if disclosed.
    FMT_SMF.1FMT_SMF.1 supports the objective by requiring the TSF to implement management functions that control the extent to which user data is collected and disseminated.
    FMT_SMF_EXT.3FMT_SMF_EXT.3 supports the objective by requiring the TSF to identify its authorized administrators so that a user knows the extent to which various administrators have access to the device.
    O.PROTECTED_​COMMS

    FCS_CKM.1FCS_CKM.1 supports the objective by defining the key generation algorithms that are used for protected communications.
    FCS_CKM.2/UNLOCKEDFCS_CKM.2/UNLOCKED supports the objective by defining the key establishment algorithms that are used for protected communications.
    FCS_COP.1/ENCRYPTFCS_COP.1/ENCRYPT supports the objective by requiring the TSF to implement symmetric encryption algorithms that are used in support of protected communications.
    FCS_COP.1/HASHFCS_COP.1/HASH supports the objective by requiring the TSF to implement hash algorithms that are used in support of protected communications.
    FCS_COP.1/KEYHMACFCS_COP.1/KEYHMAC supports the objective by requiring the TSF to implement HMAC algorithms that are used in support of protected communications.
    FCS_COP.1/SIGNFCS_COP.1/SIGN supports the objective by requiring the TSF to implement digital signature algorithms that are used in support of protected communications.
    FCS_HTTPS_EXT.1FCS_HTTPS_EXT.1 supports the objective by defining the TOE's implementation of HTTPS if this protocol is used for protected communications.
    FCS_RBG_EXT.1FCS_RBG_EXT.1 supports the objective by requiring the TSF to implement deterministic random bit generation algorithms that are used in support of protected communications.
    FCS_RBG_EXT.2FCS_RBG_EXT.2 supports the objective by requiring the TSF to save the DRBG state between reboots to ensure availability of this service.
    FCS_RBG_EXT.3FCS_RBG_EXT.3 supports the objective by defining the TSF's implementation of the SP 800-90A Personalization String for applications that require this.
    FCS_SRV_EXT.1FCS_SRV_EXT.1 supports the objective by defining the cryptographic services that the TSF must make available to third-party applications, which includes those that can support protected communications.
    FCS_SRV_EXT.2FCS_SRV_EXT.2 supports the objective by requiring the TSF to make keys in its secure key storage available for use in encryption and signing operations.
    FDP_BLT_EXT.1FDP_BLT_EXT.1 supports the objective by limiting the applications that are authorized to use the Bluetooth interface, which may include a trusted channel.
    FDP_IFC_EXT.1FDP_IFC_EXT.1 supports the objective by requiring the TSF to have either its own IPsec VPN client or interface that allows a third-party VPN client to be deployed on it.
    FDP_STG_EXT.1FDP_STG_EXT.1 supports the objective by requiring the TSF to implement a protected key storage that can be used to protect persistent keys used for protected communications from disclosure.
    FDP_UPC_EXT.1/APPSFDP_UPC_EXT.1/APPS supports the objective by defining the protected communications channels that it allows third-party applications to invoke.
    FDP_UPC_EXT.1/BLUETOOTHFDP_UPC_EXT.1/BLUETOOTH supports the objective by defining the Bluetooth interfaces that it allows third-party applications to invoke.
    FIA_X509_EXT.1FIA_X509_EXT.1 supports the objective by defining the rules the TSF uses to determine if a presented X.509 certificate is valid.
    FIA_X509_EXT.2FIA_X509_EXT.2 supports the objective by requiring the TSF to enumerate its uses of X.509 certificates (including protected communications) and its behavior when a certificate's revocation status is undetermined.
    FIA_X509_EXT.3FIA_X509_EXT.3 supports the objective by requiring the TSF to provide a certificate validation service to third-party applications.
    FIA_X509_EXT.4FIA_X509_EXT.4 supports the objective by defining the implementation of EST as a method by which the TSF can obtain an X.509 certificate for its own use.
    FIA_X509_EXT.5FIA_X509_EXT.5 supports the objective by defining the implementation of Certificate Request Messages as a method by which the TSF can obtain an X.509 certificate for its own use.
    FPT_BLT_EXT.1FPT_BLT_EXT.1 supports the objective by requiring the TSF to disable certain Bluetooth profiles when they are inactive such that explicit user authorization is required to re-enable them.
    O.STORAGE

    FCS_CKM.2/LOCKEDFCS_CKM.2/LOCKED supports the objective by defining the key establishment mechanism used for keys that protect data at rest when the TOE is in a locked state.
    FCS_CKM_EXT.1FCS_CKM_EXT.1 supports the objective by defining the TOE's root encryption key that is used to protect data at rest.
    FCS_CKM_EXT.2FCS_CKM_EXT.2 supports the objective by defining how the TSF creates data encryption keys that are used to protect data at rest.
    FCS_CKM_EXT.3FCS_CKM_EXT.3 supports the objective by defining the key encryption keys the TOE uses to protect data at rest and how they are created.
    FCS_CKM_EXT.4FCS_CKM_EXT.4 supports the objective by requiring the TSF to destroy keys and key material that could otherwise be used to compromise data at rest.
    FCS_CKM_EXT.5FCS_CKM_EXT.5 supports the objective by defining the mechanism the TSF uses to perform a wipe operation that securely destroys data at rest.
    FCS_CKM_EXT.6FCS_CKM_EXT.6 supports the objective by requiring the TSF to use secure salts when performing cryptographic operations that require them.
    FCS_CKM_EXT.7FCS_CKM_EXT.7 supports the objective by ensuring that the TOE's root encryption key cannot be disclosed.
    FCS_COP.1/CONDITIONFCS_COP.1/CONDITION supports the objective by defining a key derivation function that can be used to protect data at rest.
    FCS_COP.1/ENCRYPTFCS_COP.1/ENCRYPT supports the objective by defining a symmetric encryption/decryption function that can be used to protect data at rest.
    FCS_COP.1/HASHFCS_COP.1/HASH supports the objective by defining a hash function that can be used to protect data at rest.
    FCS_COP.1/KEYHMACFCS_COP.1/KEYHMAC supports the objective by defining an HMAC function that can be used to protect data at rest.
    FCS_COP.1/SIGNFCS_COP.1/SIGN supports the objective by defining a digital signature function that can be used to protect data at rest.
    FCS_IV_EXT.1FCS_IV_EXT.1 supports the objective by ensuring that any IVs the TSF generates for AES keys are generated in an appropriate manner based on the relevant standards.
    FCS_RBG_EXT.1FCS_RBG_EXT.1 supports the objective by defining random bit generation function that can be used to protect data at rest.
    FCS_STG_EXT.1FCS_STG_EXT.1 supports the objective by requiring the TSF to implement a hardware or software key store to protect key data at rest.
    FCS_STG_EXT.2FCS_STG_EXT.2 supports the objective by defining the confidentiality mechanism used to protect stored key data from unauthorized disclosure.
    FCS_STG_EXT.3FCS_STG_EXT.3 supports the objective by defining the integrity mechanism used to protect stored key data from unauthorized modification.
    FDP_ACF_EXT.3FDP_ACF_EXT.3 supports the objective by ensuring that the TSF does not permit write and execute permissions on stored data to be granted simultaneously.
    FDP_DAR_EXT.1FDP_DAR_EXT.1 supports the objective by requiring the TSF to encrypt all sensitive data using data encryption keys.
    FDP_DAR_EXT.2FDP_DAR_EXT.2 supports the objective by requiring the TSF to provide a mechanism to mark data as sensitive so that it can be subject to encryption.
    FIA_UAU_EXT.1FIA_UAU_EXT.1 supports the objective by requiring the presentation of a valid authorization factor in order to decrypt sensitive data at rest.
    FPT_JTA_EXT.1FPT_JTA_EXT.1 supports the objective by requiring the TSF to enforce access controls against JTAG so that this interface cannot be used to disclose data at rest.
    FPT_KST_EXT.1FPT_KST_EXT.1 supports the objective by requiring the TSF to prevent the storage of plaintext key data in readable non-volatile memory.
    FPT_KST_EXT.2FPT_KST_EXT.2 supports the objective by requiring the TSF to prevent any transmission of plaintext key material outside of the TOE boundary.
    FPT_KST_EXT.3FPT_KST_EXT.3 supports the objective by requiring the TSF to prevent export of any stored plaintext keys.

    5.2 Security Assurance Requirements

    The Security Objectives

    for the TOE

    in Section

    5

    4 Security

    Requirements

    Objectives were constructed to address threats identified in

    Section 3

    .

    1 Threats.

    The Security Functional Requirements (SFRs) in

    Section 5.1 Security Functional Requirements

    are a formal instantiation of the Security Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing.


    This section lists the set of SARs from CC part 3 that are required in evaluations against this PP. Individual Evaluation Activities (EAs) to be performed are specified both in Section 5 Security Requirements as well as in this section.


    The general model for evaluation of TOEs against STs written to conform to this PP is as follows:


    After the ST has been approved for evaluation, the CCTL ITSEF will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The CCTL ITSEF is expected to perform actions mandated by the Common Evaluation Methodology (CEM) for the ASE and ALC SARs. The CCTL ITSEF also performs the evaluation activities Evaluation Activities contained within Section 5 Security Requirements , which are intended to be an interpretation of the other CEM assurance evaluation requirements as they apply to the specific technology instantiated in the TOE. The evaluation activities Evaluation Activities that are captured in Section 5 Security Requirements also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP. The results of these activities will be documented and presented (along with the administrative guidance used) for validation.


    The TOE Security Assurance Requirements are identified in Table 8.


    Table 8: Security Assurance Requirements

    Assurance ClassAssurance Components
    Security Target (ASE)Conformance Claims (ASE_CCL.1)
    Extended Components Definition (ASE_ECD.1)
    ST Introduction (ASE_INT.1)
    Security Objectives for the Operational Environment (ASE_OBJ.1)
    Stated Security Requirements (ASE_REQ.1)
    Security Problem Definition (ASE_SPD.1)
    TOE Summary Specification (ASE_TSS.1)
    Development (ADV)Basic Functional Specification (ADV_FSP.1)
    Guidance Documents (AGD)Operational User Guidance (AGD_OPE.1)
    Preparative Procedures (AGD_PRE.1)
    Life Cycle Support (ALC)Labeling of the TOE (ALC_CMC.1)
    TOE CM Coverage (ALC_CMS.1)
    Timely Security Updates (ALC_TSU_EXT)
    Tests (ATE)Independent Testing – Sample (ATE_IND.1)
    Vulnerability Assessment (AVA)Vulnerability Survey (AVA_VAN.1)

    5.2.1 Class ASE: Security Target

    As The ST is evaluated as per ASE activities defined in [CEM]. the CEM for ASE_CCL.1, ASE_ECD.1, ASE_INT.1, ASE_OBJ.1, ASE_REQ.1, ASE_SPD.1, and ASE_TSS.1. In addition, there may be Evaluation Activities specified within that call for necessary descriptions to be included in the TSS that are specific to the TOE technology type.

    5.2.2 Class ADV: Development

    The design information about the TOE is contained in the guidance documentation available to the end user as well as the TSS portion of the ST. The TOE developer must concur with the description of the product that is contained in the TSS as it relates to the functional requirements. The evaluation activities contained in Section 5.1 Security Functional Requirements should provide the ST authors with sufficient information to determine the appropriate content for the TSS section. , and any additional information required by this PP that is not to be made public.

    ADV_FSP.1 Basic Functional Specification (ADV_FSP.1)

    The functional specification describes the TOE Security Functions Interface (TSFIs). It is not necessary to have a formal or complete specification of these interfaces. Additionally, because TOEs conforming to this PP will necessarily have interfaces to the Operational Environment that are not directly invokable by TOE users, there is little point specifying that such interfaces be described in and of themselves since only indirect testing of such interfaces may be possible. For this PP, the activities for this family should focus on understanding the interfaces presented in the TSS in response to the functional requirements and the interfaces presented in the AGD documentation. No additional “functional specification” "functional specification" documentation is necessary to satisfy the evaluation activities specified.


    The interfaces that need to be evaluated are characterized through the information needed to perform the assurance evaluation activities listed, rather than as an independent, abstract list.

    Developer action elements:

    The developer shall provide a functional specification.
    The developer shall provide a tracing from the functional specification to the SFRs.
    Application Note: As indicated in the introduction to this section, the functional specification is comprised of the information contained in the AGD_OPE and , AGD_PRE documentation. , and the API information that is provided to application developers, including the APIs that require privilege to invoke.


    The developer may reference a website accessible to application developers and the evaluator. The API documentation must include those interfaces required in this profile. The API documentation must clearly indicate to which products and versions each available function applies.


    The evaluation activities in the functional requirements point to evidence that should exist in the documentation and TSS section; since these are directly associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary.

    Content and presentation elements:

    The functional specification shall describe the purpose and method of use for each SFR-enforcing and SFR-supporting TSFI.
    The functional specification shall identify all parameters associated with each SFR-enforcing and SFR-supporting TSFI.
    The functional specification shall provide rationale for the implicit categorization of interfaces as SFR-non-interfering.
    The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification.

    Evaluator action elements:

    The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
    The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs.
    There are no specific evaluation activities associated with these SARs, except ensuring the information is provided. The functional specification documentation is provided to support the evaluation activities described in Section 5.1 Security Functional Requirements , and other activities described for AGD, ATE, and AVA SARs. The requirements on the content of the functional specification information is implicitly assessed by virtue of the other evaluation activities being performed; if the evaluator is unable to perform an activity because there is insufficient interface information, then an adequate functional specification has not been provided.

    5.2.3 Class AGD: Guidance Documentation

    The guidance documents will be provided with the ST. Guidance must include a description of how the IT personnel verifies that the Operational Environment can fulfill its role for the security functionality. The documentation should be in an informal style and readable by the IT personnel.


    Guidance must be provided for every operational environment that the product supports as claimed in the ST. This guidance includes instructions : ; and .
    Guidance pertaining to particular security functionality is also provided; requirements on such guidance are contained in the evaluation activities specified with each requirement.

    AGD_OPE.1 Operational User Guidance (AGD_OPE.1)

    Developer action elements:

    The developer shall provide operational user guidance.
    Application Note: The operational user guidance does not have to be contained in a single document. Guidance to users, administrators and application developers can be spread among documents or web pages. Where appropriate, the guidance documentation is expressed in the eXtensible Configuration Checklist Description Format (XCCDF) to support security automation.


    Rather than repeat information here, the developer should review the evaluation activities for this component to ascertain the specifics of the guidance that the evaluator will be checking for. This will provide the necessary information for the preparation of acceptable guidance.

    Content and presentation elements:

    The operational user guidance shall describe, for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings.
    Application Note: User and administrator (e.g., MDM agent), and application developer are to be considered in the definition of user role.
    The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the TOE in a secure manner.
    The operational user guidance shall describe, for each user role, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate.
    The operational user guidance shall, for each user role, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF.
    The operational user guidance shall identify all possible modes of operation of the TOE OS (including operation following failure or operational error), their consequences, and implications for maintaining secure operation.
    The operational user guidance shall, for each user role, describe the security measures to be followed in order to fulfill the security objectives for the operational environment as described in the ST.
    The operational user guidance shall be clear and reasonable.

    Evaluator action elements:

    The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
    Some of the contents of the operational guidance will be are verified by the evaluation activities in Section 5.1 Security Functional Requirements and evaluation of the TOE according to the [CEM]. The following additional information is also required.

    If cryptographic functions are provided by the TOE, the
    The operational guidance shall contain a list of natively installed applications and any relevant version numbers. If any third party vendors are permitted to install applications before purchase by the end user or enterprise, these applications shall also be listed.


    The operational guidance shall contain instructions for configuring the cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning to the administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE.


    The documentation must describe the process for verifying updates to the TOE by verifying a digital signature – this may be done by the TOE or the underlying platform.

    The evaluator shall verify that this process includes the following steps:
    • Instructions for obtaining the update itself. This should include instructions for making the update accessible to the TOE (e.g., placement in a specific directory).
    • Instructions for initiating the update process, as well as discerning whether the process was successful or unsuccessful. This includes generation of the hash/digital signature.
    The TOE will likely contain security functionality that does not fall in the scope of evaluation under this PP. The operational guidance shall make it clear to an administrator which security functionality is covered by the evaluation activities.

    AGD_PRE.1 Preparative Procedures (AGD_PRE.1)

    Developer action elements:

    The developer shall provide the TOE, including its preparative procedures.
    Application Note: As with the operational guidance, the developer should look to the evaluation activities to determine the required content with respect to preparative procedures.

    Content and presentation elements:

    The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with the developer's delivery procedures.
    The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST.

    Evaluator action elements:

    The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
    The evaluator shall apply the preparative procedures to confirm that the TOE OS can be prepared securely for operation.
    As indicated in the introduction above, there are significant expectations with respect to the documentation—especially when configuring the operational environment to support TOE functional requirements. The evaluator shall check to ensure that the guidance provided for the TOE adequately addresses all platforms claimed for the TOE in the ST.

    5.2.4 Class ALC: Life-cycle Support

    At the assurance level provided for TOEs conformant to this PP, life-cycle support is limited to end-user-visible aspects of the life-cycle, rather than an examination of the TOE vendor’s development and configuration management process. This is not meant to diminish the critical role that a developer’s practices play in contributing to the overall trustworthiness of a product; rather, it is a reflection on the information to be made available for evaluation at this assurance level.

    ALC_CMC.1 Labeling of the TOE (ALC_CMC.1)

    This component is targeted at identifying the TOE such that it can be distinguished from other products or versions from the same vendor and can be easily specified when being procured by an end user.

    Developer action elements:

    The developer shall provide the TOE and a reference for the TOE.

    Content and presentation elements:

    The application TOE shall be labeled with a unique reference.Application Note: Unique reference information includes:
    • Application Name
    • Application Version
    • Application Description
    • Platform on which Application Runs
    • Software Identification (SWID) tags, if available

    Evaluator action elements:

    The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
    The evaluator shall check the ST to ensure that it contains an identifier (such as a product name/version number) that specifically identifies the version that meets the requirements of the ST. Further, the evaluator shall check the AGD guidance and TOE samples received for testing to ensure that the version number is consistent with that in the ST. If the vendor maintains a web site advertising the TOE, the evaluator shall examine the information on the web site to ensure that the information in the ST is sufficient to distinguish the product.

    ALC_CMS.1 TOE CM Coverage (ALC_CMS.1)

    Given the scope of the TOE and its associated evaluation evidence requirements, this component’s evaluation activities are covered by the evaluation activities listed for ALC_CMC.1.

    Developer action elements:

    The developer shall provide a configuration list for the TOE.

    Content and presentation elements:

    The configuration list shall include the following: the TOE itself; and the evaluation evidence required by the SARs.
    The configuration list shall uniquely identify the configuration items.

    Evaluator action elements:

    ALC_CMS.1
    The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
    Evaluation Activities
    Note: The "evaluation evidence required by the SARs" in this PP is limited to the information in the ST coupled with the guidance provided to administrators and users under the AGD requirements. By ensuring that the TOE is specifically identified and that this identification is consistent in the ST and in the AGD guidance (as done in the evaluation activity for ALC_CMC.1), the evaluator implicitly confirms the information required by this component.


    Life-cycle support is targeted aspects of the developer’s life-cycle and instructions to providers of applications for the developer’s devices, rather than an in-depth examination of the TSF manufacturer’s development and configuration management process. This is not meant to diminish the critical role that a developer’s practices play in contributing to the overall trustworthiness of a product; rather, it’s a reflection on the information to be made available for evaluation.
    The evaluator shall ensure that the developer has identified (in public-facing development guidance documentation for application developers concerning the targeted their platform) one or more development environments appropriate for use in developing applications for the developer’s platform. For each of these development environments, the developer shall provide information on how to configure the environment to ensure that buffer overflow protection mechanisms in the environment(s) environments are invoked (e.g., compiler and linker flags). The evaluator shall ensure that this documentation also includes an indication of whether such protections are on by default, or have to be specifically enabled.


    The evaluator shall ensure that the TSF is uniquely identified (with respect to other products from the TSF vendor), and that documentation provided by the developer in association with the requirements in the ST is associated with the TSF using this unique identification.

    ALC_TSU_EXT.1 Timely Security Updates

    This component requires the TOE developer, in conjunction with any other necessary parties, to provide information as to how the end-user devices are updated to address security issues in a timely manner. The documentation describes the process of providing updates to the public from the time a security flaw is reported/discovered, to the time an update is released. This description includes the parties involved (e.g., the developer, cellular carriers(s) ) and the steps that are performed (e.g., developer testing, carrier testing), including worst-case time periods, before an update is made available to the public.

    Developer action elements:

    The developer shall provide a description in the TSS of how timely security updates are made to the TOE. Note: Application developers must support updates to their products for purposes of fixing security vulnerabilities.
    The developer shall provide a description in the TSS of how users are notified when updates change security properties or the configuration of the product.

    Content and presentation elements:

    The description shall include the process for creating and deploying security updates for the TOE software.
    Note: The software to be described includes the operating systems of the application processor and the baseband processor, as well as any firmware and applications. The process description includes the TOE developer processes as well as any third-party (carrier) processes. The process description includes each deployment mechanism (e.g., over-the-air updates, per-carrier updates, downloaded updates).
    The description shall express the time window as the length of time, in days, between public disclosure of a vulnerability and the public availability of security updates to the TOE.
    Note: The total length of time may be presented as a summation of the periods of time that each party (e.g., TOE developer, mobile carrier) on the critical path consumes. The time period until public availability per deployment mechanism may differ; each is described.
    The description shall include the mechanisms publicly available for reporting security issues pertaining to the TOE.
    Note: The reporting mechanism could include web sites, email addresses, as well as a means to protect the sensitive nature of the report (e.g., public keys that could be used to encrypt the details of a proof-of-concept exploit).
    The description shall include where users can seek information about the availability of new updates including details (e.g. CVE identifiers) of the specific public vulnerabilities corrected by each update.
    Note: The purpose of providing this information is so that users and enterprises can determine which devices are susceptible to publicly known vulnerabilities so that they can make appropriate risk decisions, such as limiting access to enterprise resources until updates are installed.

    Evaluator action elements:

    The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
    The evaluator shall verify that the TSS contains a description of the timely security update process used by the developer to create and deploy security updates. The evaluator shall verify that this description addresses the entire application TOE OS, the firmware, and bundled applications, each. The evaluator shall also verify that, in addition to the TOE developer’s process, any carrier or other third-party processes are also addressed in the description. The evaluator shall also verify that each mechanism for deployment of security updates is described.


    The evaluator shall verify that, for each deployment mechanism described for the update process, the TSS lists a time between public disclosure of a vulnerability and public availability of the security update to the TOE patching this vulnerability, to include any third-party or carrier delays in deployment. The evaluator shall verify that this time is expressed in a number or range of days.


    The evaluator shall verify that this description includes the publicly available mechanisms (including either an email address or website) for reporting security issues related to the TOE. The evaluator shall verify that the description of this mechanism includes a method for protecting the report either using a public key for encrypting email or a trusted channel for a website.


    The evaluator shall verify that the description includes where users can seek information about the availability of new security updates including details of the specific public vulnerabilities corrected by each update. The evaluator shall verify that the description includes the minimum amount of time that the TOE is expected to be supported with security updates, and the process by which users can seek information about when the TOE is no longer expected to receive security updates.

    5.2.5 Class ATE: Tests

    Testing is specified for functional aspects of the system as well as aspects that take advantage of design or implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces with dependency on the availability of design information. One of the primary outputs of the evaluation process is the test report as specified in the following requirements.


    Since many of the APIs are not exposed at the user interface (e.g., touch screen), the ability to stimulate the necessary interfaces requires a developer’s test environment. This test environment will allow the evaluator, for example, to access APIs and view file system information that is not available on consumer Mobile Devices.

    ATE_IND.1 Independent Testing – Conformance (ATE_IND.1)

    Testing is performed to confirm the functionality described in the TSS as well as the administrative (including configuration and operational) documentation provided. The focus of the testing is to confirm that the requirements specified in Section 5.1 Security Functional Requirements being met, although some additional testing is specified for SARs in Section 5.2 Security Assurance Requirements. The evaluation activities Evaluation Activities identify the additional testing activities associated with these components. The evaluator produces a test report documenting the plan for and results of testing, as well as coverage arguments focused on the platform/TOE combinations that are claiming conformance to this PP. Given the scope of the TOE and its associated evaluation evidence requirements, this component’s evaluation activities are covered by the evaluation activities listed for ALC_CMC.1.

    Developer action elements:

    The developer shall provide the TOE for testing.Application Note: The developer must provide at least one product instance of the TOE for complete testing on at least platform regardless of equivalency. See the Equivalency Appendix for more details.

    Content and presentation elements:

    The TOE shall be suitable for testing.

    Evaluator action elements:

    The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
    The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified.Application Note: The evaluator shall test the application on the most current fully patched version of the platform.
    The evaluator shall prepare a test plan and report documenting the testing aspects of the system, including any application crashes during testing. The evaluator shall determine the root cause of any application crashes and include that information in the report. The test plan covers all of the testing actions contained in the [CEM] and the body of this PP’s evaluation activitiesEvaluation Activities.

    While it is not necessary to have one test case per test listed in an evaluation activity, the evaluator must document in the test plan that each applicable testing requirement in the ST is covered.


    The test plan identifies the platforms to be tested, and for those platforms not included in the test plan but included in the ST, the test plan provides a justification for not testing the platforms. This justification must address the differences between the tested platforms and the untested platforms, and make an argument that the differences do not affect the testing to be performed. It is not sufficient to merely assert that the differences have no effectaffect; rationale must be provided. If all platforms claimed in the ST are tested, then no rationale is necessary.


    The test plan describes the composition of each platform to be tested, and any setup that is necessary beyond what is contained in the AGD documentation. It should be noted that the evaluator is expected to follow the AGD documentation for installation and setup of each platform either as part of a test or as a standard pre-test condition. This may include special test drivers or tools. For each driver or tool, an argument (not just an assertion) should be provided that the driver or tool will not adversely affect the performance of the functionality by the TOE and its platform.

    This also includes the configuration of the cryptographic engine to be used. The cryptographic algorithms implemented by this engine are those specified by this PP and used by the cryptographic protocols being evaluated (e.g IPsec, TLS/HTTPS, SSH).


    The test plan identifies high-level test objectives as well as the test procedures to be followed to achieve those objectives. These procedures include expected results.

    The test report (which could just be an annotated version of the test plan) details the activities that took place when the test procedures were executed, and includes the actual results of the tests. This shall be a cumulative account, so if there was a test run that resulted in a failure; a fix installed; and then a successful re-run of the test, the report would show a “fail” and “pass” "fail" and "pass" result (and the supporting details), and not just the “pass” "pass" result.

    5.2.6 Class AVA: Vulnerability Assessment

    For the current generation of this protection profile, the evaluation lab is expected to survey open sources to discover what vulnerabilities have been discovered in these types of products. In most cases, these vulnerabilities will require sophistication beyond that of a basic attacker. Until penetration tools are created and uniformly distributed to the evaluation labs, the evaluator will not be expected to test for these vulnerabilities in the TOE. The labs will be expected to comment on the likelihood of these vulnerabilities given the documentation provided by the vendor. This information will be used in the development of penetration testing tools and for the development of future protection profiles.

    AVA_VAN.1 Vulnerability Survey (AVA_VAN.1)

    Developer action elements:

    The developer shall provide the TOE for testing.

    Content and presentation elements:

    The application TOE shall be suitable for testing.Application Note: Suitability for testing means not being obfuscated or packaged in such a way as to disrupt either static or dynamic analysis by the evaluator.

    Evaluator action elements:

    The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence.
    The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE.
    Application Note: Public domain sources include the Common Vulnerabilities and Exposures (CVE) dictionary for publicly-known vulnerabilities. Public domain sources also include sites which provide free checking of files for viruses.
    The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack potential.
    The evaluator shall generate a report to document their findings with respect to this requirement. This report could physically be part of the overall test report mentioned in ATE_IND, or a separate document. The evaluator performs a search of public information to find vulnerabilities that have been found in similar applications with a particular focus on network protocols the application uses and document formats it parses.

    mobile devices and the implemented communication protocols in general, as well as those that pertain to the particular TOE. The evaluator documents the sources consulted and the vulnerabilities found in the report.


    For each vulnerability found, the evaluator either provides a rationale with respect to its non-applicability, or the evaluator formulates a test (using the guidelines provided in ATE_IND) to confirm the vulnerability, if suitable. Suitability is determined by assessing the attack vector needed to take advantage of the vulnerability. If exploiting the vulnerability requires expert skills and an electron microscope, for instance, then a test would not be suitable and an appropriate justification would be formulated. For Windows, Linux, macOS and Solaris: The evaluator shall also run a virus scanner with the most current virus definitions against the application files and verify that no files are flagged as malicious.

    Appendix A - Optional Requirements

    As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the TOE) are contained in the body of this PP. This appendix contains three other types of optional requirements that may be included in the ST, but are not required in order to conform to this PP. However, applied modules, packages and/or use cases may refine specific requirements as mandatory. :

    The first type (, defined in Appendix A.1 Strictly Optional Requirements) , are strictly optional requirements that are independent of the TOE implementing any function. If the TOE fulfills meets any of these requirements or supports a certain functionality, the vendor is encouraged to include claim the associated SFRs in the ST, but are doing so is not required in order to conform to this PP.

    The second type (, defined in Appendix A.2 Objective Requirements) , are objective requirements that . These describe security functionality that is not yet widely available in commercial technology. The Objective requirements are not currently mandated in the body of by this PP, but will be included mandated in the baseline requirements in future versions of this PP. Adoption by vendors is encouraged and expected as soon as possible, but claiming these SFRs is not required in order to conform to this PP.

    The third type (, defined in Appendix A.3 Implementation-Based dependent Requirements) , are dependent on the TOE implementing a particular functionImplementation-dependent requirements. If the TOE fulfills any of these requirements, the vendor must either add the related SFR or disable the functionality for the evaluated configuration implements the product features associated with the listed SFRs, either the SFRs must be claimed or the product features must be disabled in the evaluated ocnfiguration.

    A.1 Strictly Optional Requirements

    A.1.1

    Cryptographic Support (FCS

    Class: Identification and Authentication (FIA)

    FCS

    FIA_

    CKM.1/SK Cryptographic Symmetric Key Generation
    FCS_CKM.1.1/SK
    The application shall generate symmetric cryptographic keys using a Random Bit Generator as specified in FCS_RBG_EXT.1 and specified cryptographic key sizes [selection: ].
    Application Note: Symmetric keys may be used to generate keys along the key chain.
    Evaluation Activities
    FCS_CKM.1/SK
    TSS
    The evaluator shall review the TSS to determine that it describes how the functionality described by FCS_RBG_EXT.1 is invoked.

    If the application is relying on random bit generation from the host platform, the evaluator shall verify the TSS includes the name/manufacturer of the external RBG and describes the function call and parameters used when calling the external DRBG function. If different external RBGs are used for different platforms, the evaluator shall verify the TSS identifies each RBG for each platform. Also, the evaluator shall verify the TSS includes a short description of the vendor's assumption for the amount of entropy seeding the external DRBG. The evaluator uses the description of the RBG functionality in FCS_RBG_EXT or documentation available for the operational environment to determine that the key size being requested is identical to the key size and mode to be used for the encryption/decryption of the user data.

    Guidance
    None.

    Tests
    None.

    A.2 Objective Requirements

    A.2.1 Protection of the TSF (FPT)

    FPT_API_EXT.2 Use of Supported Services and APIs

    FPT_API_EXT.2.1
    The application [selection: shall use platform-provided libraries, does not implement functionality] for parsing [assignment: list of formats parsed that are included in the IANA MIME media types].
    Application Note: The IANA MIME types are listed at http://www.iana.org/assignments/media-types and include many image, audio, video, and content file formats. This requirement does not apply if providing parsing services is the purpose of the application.
    Evaluation Activities FPT_API_EXT.

    UAU_EXT.4 Secondary User Authentication

    The TSF shall provide a secondary authentication mechanism for accessing Enterprise applications and resources. The secondary authentication mechanism shall control access to the Enterprise application and shared resources and shall be incorporated into the encryption of protected and sensitive data belonging to Enterprise applications and shared resources.
    Application Note: For the BYOD use case, Enterprise applications and data must be protected using a different password than the user authentication to gain access to the personal applications and data, if configured.


    This requirement must be included in the ST if the TOE implements a container solution, in which there is a separate authentication, to separate user and Enterprise applications and resources.
    The TSF shall require the user to present the secondary authentication factor prior to decryption of Enterprise application data and Enterprise shared resource data.
    Application Note: The intent of this requirement is to prevent decryption of protected Enterprise application data and Enterprise shared resource data before the user has authenticated to the device using the secondary authentication factor. Enterprise shared resource data consists of the FDP_ACF_EXT.2.1 selections.
    TSS
    There are no TSS evaluation activities for this element.


    Guidance
    There are no guidance evaluation activities for this element.


    Tests
    The Evaluation Activities for any selected requirements related to device authentication must be separately performed for the secondary authentication mechanism (in addition to activities performed for the primary authentication mechanism). The requirements are: FIA_UAU.6/CREDENTIAL, FIA_UAU.6/LOCKED, FIA_PMG_EXT.1, FIA_TRT_EXT.1, FIA_UAU.7, FIA_UAU_EXT.2, FTA_SSL_EXT.1, FCS_STG_EXT.2, FMT_SMF.1/FMT_MOF_EXT.1 #1, #2, #8, #21, and #36.


    Additionally, FIA_AFL_EXT.1 must be met, except that in FIA_AFL_EXT.1.2 the separate test is performed with the text "wipe of all protected data" changed to "wipe of all Enterprise application data and all Enterprise shared resource data."
    TSS
    The evaluator shall verify that the TSS
    lists the IANA MIME media types (as described by http://www.iana.org/assignments/media-types ) for all formats the application processes and that it maps those formats to parsing services provided by the platform.
    Guidance
    None.

    Tests
    None.

    A.3 Implementation-Based Requirements

    This PP does not define any Implementation-Based requirements.

    Appendix B - Selection-Based Requirements

    As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the TOE or its underlying platform) are contained in the body of this PP. There are additional requirements based on selections in the body of the PP: if certain selections are made, then additional requirements below must be included.

    B.1 Cryptographic Support (FCS)

    FCS_CKM.1/AK Cryptographic Asymmetric Key Generation

    The inclusion of this selection-based component depends upon selection in FCS_CKM.1.1.
    FCS_CKM.1.1/AK
    The application shall [selection: ] to generate asymmetric cryptographic keys in accordance with a specified cryptographic key generation algorithm [selection: ].
    Application Note: The ST author shall select all key generation schemes used for key establishment and entity authentication. When key generation is used for key establishment, the schemes in FCS_CKM.2.1 and selected cryptographic protocols must match the selection. When key generation is used for entity authentication, the public key is expected to be associated with an X.509v3 certificate.

    If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation.
    Evaluation Activities
    FCS_CKM.1.1/AK
    TSS
    The evaluator shall ensure that the TSS identifies the key sizes supported by the TOE. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme.

    If the application "invokes platform-provided functionality for asymmetric key generation," then the evaluator shall examine the TSS to verify that it describes how the key generation functionality is invoked.

    Guidance
    The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key generation scheme(s) and key size(s) for all uses defined in this PP.

    Tests
    If the application "implements asymmetric key generation," then the following test activities shall be carried out.

    Evaluation Activity Note: The following tests may require the developer to provide access to a developer environment that provides the evaluator with tools that are typically available to end-users of the application.

    Key Generation for FIPS PUB 186-4 RSA Schemes

    The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d. Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include:
    1. Random Primes:
    2. Primes with Conditions:
    To test the key generation method for the Random Provable primes method and for all the Primes with Conditions methods, the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. This includes the random seed(s), the public exponent of the RSA key, and the desired key length. For each key length supported, the evaluator shall have the TSF generate 25 key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated from a known good implementation.

    If possible, the Random Probable primes method should also be verified against a known good implementation as described above. Otherwise, the evaluator shall have the TSF generate 10 keys pairs for each supported key length nlen and verify: Key Generation for Elliptic Curve Cryptography (ECC)

    FIPS 186-4 ECC Key Generation Test For each supported NIST curve, i.e., P-256, P-384 and P-521, the evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation.

    FIPS 186-4 Public Key Verification (PKV) Test For each supported NIST curve, i.e., P-256, P-384 and P-521, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e., correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values.

    Key Generation for Finite-Field Cryptography (FFC)

    The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and public key y. The Parameter generation specifies 2 ways (or methods) to generate the cryptographic prime q and the field prime p:

    Cryptographic and Field Primes: and two ways to generate the cryptographic group generator g:

    Cryptographic Group Generator: The Key generation specifies 2 ways to generate the private key x:

    Private Key: The security strength of the RBG must be at least that of the security offered by the FFC parameter set. To test the cryptographic and field prime generation method for the provable primes method and/or the group generator g for a verifiable process, the evaluator must seed the TSF parameter generation routine with sufficient data to deterministically generate the parameter set. For each key length supported, the evaluator shall have the TSF generate 25 parameter sets and key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated from a known good implementation. Verification must also confirm for each FFC parameter set and key pair.

    Diffie-Hellman Group 14 and FFC Schemes using “safe-prime” groups

    Testing for FFC Schemes using Diffie-Hellman group 14 and/or safe-prime groups is done as part of testing in CKM.2.1.

    FCS_CKM.1/PBKDF Password Conditioning

    The inclusion of this selection-based component depends upon selection in FCS_STO_EXT.1.1.
    FCS_CKM.1.1/PBKDF
    A password/passphrase shall perform [assignment: Password-based Key Derivation Functions] in accordance with a specified cryptographic algorithm as specified in FCS_COP.1/KeyedHash, with [assignment: positive integer of 1,000 or more] iterations, and output cryptographic key sizes [selection: 128, 256] that meet the following [NIST SP 800-132].
    FCS_CKM.1.2/PBKDF
    The TSF shall generate salts using a RBG that meets FCS_RGB_EXT.1 and with entropy corresponding to the security strength selected for PBKDF in FCS_CKM.1.1/PBKDF.
    Application Note: This should be included if selected in FCS_STO_EXT.1

    Conditioning can be performed using one of the identified hash functions or the process described in NIST SP 800-132; the method used is selected by the ST Author. SP 800-132 requires the use of a pseudo-random function (PRF) consisting of HMAC with an approved hash function. The ST author selects the hash function used, also includes the appropriate requirements for HMAC and the hash function.

    Appendix A of SP 800-132 recommends setting the iteration count in order to increase the computation needed to derive a key from a password and, therefore, increase the workload of performing a password recovery attack. A significantly higher value is recommended to ensure optimal security. This value is expected to increase to a minimum of 10,000 in a future iteration based on SP800-63.
    Evaluation Activities
    FCS_CKM.1/PBKDF
    TSS
    Support for PBKDF: The evaluator shall examine the password hierarchy TSS to ensure that the formation of all password based derived keys is described and that the key sizes match that described by the ST author. The evaluator shall check that the TSS describes the method by which the password/passphrase is first encoded and then fed to the SHA algorithm. The settings for the algorithm (padding, blocking, etc.) shall be described, and the evaluator shall verify that these are supported by the selections in this component as well as the selections concerning the hash function itself. The evaluator shall verify that the TSS contains a description of how the output of the hash function is used to form the submask that will be input into the function. For the NIST SP 800-132-based conditioning of the password/passphrase, the required evaluation activities will be performed when doing the evaluation activities for the appropriate requirements (FCS_COP.1.1/KeyedHash). No explicit testing of the formation of the submask from the input password is required. FCS_CKM.1.1/PBKDF: The ST author shall provide a description in the TSS regarding the salt generation. The evaluator shall confirm that the salt is generated using an RBG described in FCS_RBG_EXT.1.

    Guidance
    None.

    Tests
    None.

    FCS_CKM.2 Cryptographic Key Establishment

    The inclusion of this selection-based component depends upon selection in FTP_DIT_EXT.1.1.
    FCS_CKM.2.1
    The application shall [selection: invoke platform-provided functionality, implement functionality] to perform cryptographic key establishment in accordance with a specified cryptographic key establishment method:

    [selection: ].
    Application Note: The ST author shall select all key establishment schemes used for the selected cryptographic protocols. TLS requires cipher suites that use RSA-based key establishment schemes.

    The RSA-based key establishment schemes are described in Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of other sections in SP 800-56B. If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation.

    The elliptic curves used for the key establishment scheme shall correlate with the curves specified in FCS_CKM.1.1/AK.

    The domain parameters used for the finite field-based key establishment scheme are specified by the key generation according to FCS_CKM.1.1/AK.
    Evaluation Activities
    FCS_CKM.2.1
    TSS
    The evaluator shall ensure that the supported key establishment schemes correspond to the key generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme.

    Guidance
    The evaluator shall verify that the AGD guidance instructs the administrator how to configure the TOE to use the selected key establishment scheme(s).

    Tests
    Evaluation Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.

    Key Establishment Schemes

    The evaluator shall verify the implementation of the key establishment schemes supported by the TOE using the applicable tests below.

    SP800-56A Key Establishment Schemes

    The evaluator shall verify a TOE's implementation of SP800-56A key agreement schemes using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has implemented the components of the key agreement scheme according to the specifications in the Recommendation. These components include the calculation of the DLC primitives (the shared secret value Z) and the calculation of the derived keying material (DKM) via the Key Derivation Function (KDF). If key confirmation is supported, the evaluator shall also verify that the components of key confirmation have been implemented correctly, using the test procedures described below. This includes the parsing of the DKM, the generation of MACdata and the calculation of MACtag.

    Function Test

    The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement scheme-key agreement role combination, KDF type, and, if supported, key confirmation role- key confirmation type combination, the tester shall generate 10 sets of test vectors. The data set consists of one set of domain parameter values (FFC) or the NIST approved curve (ECC) per 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested.

    The evaluator shall obtain the DKM, the corresponding TOE’s public keys (static and/or ephemeral), the MAC tag(s), and any inputs used in the KDF, such as the Other Information (OtherInfo) and TOE id fields.

    If the TOE does not use a KDF defined in SP 800-56A, the evaluator shall obtain only the public keys and the hashed value of the shared secret.

    The evaluator shall verify the correctness of the TSF’s implementation of a given scheme by using a known good implementation to calculate the shared secret value, derive the keying material DKM, and compare hashes or MAC tags generated from these values.

    If key confirmation is supported, the TSF shall perform the above for each implemented approved MAC algorithm.

    Validity Test

    The Validity test verifies the ability of the TOE to recognize another party’s valid and invalid key agreement results with or without key confirmation. To conduct this test, the evaluator shall obtain a list of the supporting cryptographic functions included in the SP800-56A key agreement implementation to determine which errors the TOE should be able to recognize. The evaluator generates a set of 24 (FFC) or 30 (ECC) test vectors consisting of data sets including domain parameter values or NIST approved curves, the evaluator’s public keys, the TOE’s public/private key pairs, MACTag, and any inputs used in the KDF, such as the OtherInfo and TOE id fields.

    The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value Z, the DKM, the OtherInfo field, the data to be MACed, or the generated MACTag. If the TOE contains the full or partial (only ECC) public key validation, the evaluator will also individually inject errors in both parties’ static public keys, both parties’ ephemeral public keys and the TOE’s static private key to assure the TOE detects errors in the public key validation function and/or the partial key validation function (in ECC only). At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass).

    The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOE’s results with the results using a known good implementation verifying that the TOE detects these errors.

    SP800-56B Key Establishment Schemes

    The evaluator shall verify that the TSS describes whether the TOE acts as a sender, a recipient, or both for RSA-based key establishment schemes.

    If the TOE acts as a sender, the following evaluation activity shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme:

    To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each combination of supported key establishment scheme and its options (with or without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTS-OAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA public key, the plaintext keying material, any additional input parameters if applicable, the MacKey and MacTag if key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform a key establishment encryption operation on the TOE with the same inputs (in cases where key confirmation is incorporated, the test shall use the MacKey from the test vector instead of the randomly generated MacKey used in normal operation) and ensure that the outputted ciphertext is equivalent to the ciphertext in the test vector.
    If the TOE acts as a receiver, the following evaluation activities shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme:

    To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each combination of supported key establishment scheme and its options (with our without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTS-OAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA private key, the plaintext keying material (KeyData), any additional input parameters if applicable, the MacTag in cases where key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform the key establishment decryption operation on the TOE and ensure that the outputted plaintext keying material (KeyData) is equivalent to the plaintext keying material in the test vector. In cases where key confirmation is incorporated, the evaluator shall perform the key confirmation steps and ensure that the outputted MacTag is equivalent to the MacTag in the test vector.
    The evaluator shall ensure that the TSS describes how the TOE handles decryption errors. In accordance with NIST Special Publication 800-56B, the TOE must not reveal the particular error that occurred, either through the contents of any outputted or logged error message or through timing variations. If KTS-OAEP is supported, the evaluator shall create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800-56B section 7.2.2.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each. If KTS-KEM-KWS is supported, the evaluator shall create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800-56B section 7.2.3.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each.

    RSA-based key establishment

    The evaluator shall verify the correctness of the TSF’s implementation of RSAES-PKCS1-v1_5 by using a known good implementation for each protocol selected in FTP_DIT_EXT.1 that uses RSAES-PKCS1-v1_5.

    Diffie-Hellman Group 14

    The evaluator shall verify the correctness of the TSF’s implementation of Diffie-Hellman group 14 by using a known good implementation for each protocol selected in FTP_DIT_EXT.1 that uses Diffie-Hellman group 14.

    FFC Schemes using “safe-prime” groups

    The evaluator shall verify the correctness of the TSF’s implementation of safe-prime groups by using a known good implementation for each protocol selected in FTP_DIT_EXT.1 that uses safe-prime groups. This test must be performed for each safe-prime group that each protocol uses.

    FCS_COP.1/SKC Cryptographic Operation - Encryption/Decryption

    The inclusion of this selection-based component depends upon selection in FCS_STO_EXT.1.1, FTP_DIT_EXT.1.1.
    FCS_COP.1.1/SKC
    The application shall perform encryption/decryption in accordance with a specified cryptographic algorithm [selection: ] and cryptographic key sizes [selection: 128-bit, 256-bit].
    Application Note: This is dependent on implementing cryptographic functionality, as in FTP_DIT_EXT.1.

    For the first selection, the ST author should choose the mode or modes in which AES operates. For the second selection, the ST author should choose the key sizes that are supported by this functionality. 128-bit key size is required in order to comply with certain TLS implementations.

    Evaluation Activities
    FCS_COP.1/SKC
    TSS
    None.

    Guidance
    The evaluator checks the AGD documents to determine that any configuration that is required to be done to configure the functionality for the required modes and key sizes is present.

    Tests
    The evaluator shall perform all of the following tests for each algorithm implemented by the TSF and used to satisfy the requirements of this PP:

    AES-CBC Known Answer Tests

    There are four Known Answer Tests (KATs), described below. In all KATs, the plaintext, ciphertext, and IV values shall be 128-bit blocks. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using ciphertext values of the same form as the plaintext in the encrypt test as input and AES-CBC decryption.

    AES-CBC Multi-Block Message Test

    The evaluator shall test the encrypt functionality by encrypting an i-block message where 1 < i <= 10. The evaluator shall choose a key, an IV and plaintext message of length i blocks and encrypt the message, using the mode to be tested, with the chosen key and IV. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation. The evaluator shall also test the decrypt functionality for each mode by decrypting an i-block message where 1 < i <=10. The evaluator shall choose a key, an IV and a ciphertext message of length i blocks and decrypt the message, using the mode to be tested, with the chosen key and IV. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key and IV using a known good implementation. AES-CBC Monte Carlo Tests The evaluator shall test the encrypt functionality using a set of 200 plaintext, IV, and key 3- tuples. 100 of these shall use 128 bit keys, and 100 shall use 256 bit keys. The plaintext and IV values shall be 128-bit blocks. For each 3-tuple, 1000 iterations shall be run as follows:
                    
    						  # Input: PT, IV, Key
    						  for i = 1 to 1000:
    							if i == 1:
    								  CT[1] = AES-CBC-Encrypt(Key, IV, PT)
    								  PT = IV
    							else:
    							  CT[i] = AES-CBC-Encrypt(Key, PT) 
    							  PT = CT[i-1]
    						  
                
    The ciphertext computed in the 1000th iteration (i.e., CT[1000]) is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation.

    The evaluator shall test the decrypt functionality using the same test as for encrypt, exchanging CT and PT and replacing AES-CBC-Encrypt with AES-CBC-Decrypt.

    AES-GCM Monte Carlo Tests

    The evaluator shall test the authenticated encrypt functionality of AES-GCM for each combination of the following input parameter lengths: The evaluator shall test the encrypt functionality using a set of 10 key, plaintext, AAD, and IV tuples for each combination of parameter lengths above and obtain the ciphertext value and tag that results from AES-GCM authenticated encrypt. Each supported tag length shall be tested at least once per set of 10. The IV value may be supplied by the evaluator or the implementation being tested, as long as it is known.

    The evaluator shall test the decrypt functionality using a set of 10 key, ciphertext, tag, AAD, and IV 5-tuples for each combination of parameter lengths above and obtain a Pass/Fail result on authentication and the decrypted plaintext if Pass. The set shall include five tuples that Pass and five that Fail.

    The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

    AES-XTS Tests

    The evaluator shall test the encrypt functionality of XTS-AES for each combination of the following input parameter lengths:

    256 bit (for AES-128) and 512 bit (for AES-256) keys

    Three data unit (i.e., plaintext) lengths. One of the data unit lengths shall be a non-zero integer multiple of 128 bits, if supported. One of the data unit lengths shall be an integer multiple of 128 bits, if supported. The third data unit length shall be either the longest supported data unit length or 216 bits, whichever is smaller.

    Using a set of 100 (key, plaintext and 128-bit random tweak value) 3-tuples and obtain the ciphertext that results from XTS-AES encrypt.

    The evaluator may supply a data unit sequence number instead of the tweak value if the implementation supports it. The data unit sequence number is a base-10 number ranging between 0 and 255 that implementations convert to a tweak value internally.

    The evaluator shall test the decrypt functionality of XTS-AES using the same test as for encrypt, replacing plaintext values with ciphertext values and XTS-AES encrypt with XTS-AES decrypt.

    AES-CCM Tests It is not recommended that evaluators use values obtained from static sources such as http://csrc.nist.gov/groups/STM/cavp/documents/mac/ccmtestvectors.zip or use values not generated expressly to exercise the AES-CCM implementation.

    The evaluator shall test the generation-encryption and decryption-verification functionality of AES-CCM for the following input parameter and tag lengths: The testing for CCM consists of five tests. To determine correctness in each of the below tests, the evaluator shall compare the ciphertext with the result of encryption of the same inputs with a known good implementation.

    Variable Associated Data Test

    For each supported key size and associated data length, and any supported payload length, nonce length, and tag length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload values, and obtain the resulting ciphertext.

    Variable Payload Test

    For each supported key size and payload length, and any supported associated data length, nonce length, and tag length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload values, and obtain the resulting ciphertext.

    Variable Nonce Test

    For each supported key size and nonce length, and any supported associated data length, payload length, and tag length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload values, and obtain the resulting ciphertext.

    Variable Tag Test

    For each supported key size and tag length, and any supported associated data length, payload length, and nonce length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload values, and obtain the resulting ciphertext.

    Decryption-Verification Process Test

    To test the decryption-verification functionality of AES-CCM, for each combination of supported associated data length, payload length, nonce length, and tag length, the evaluator shall supply a key value and 15 sets of input plus ciphertext, and obtain the decrypted payload. Ten of the 15 input sets supplied should fail verification and five should pass.

    AES-CTR Tests

    Test 1: Known Answer Tests (KATs)

    There are four Known Answer Tests (KATs) described below. For all KATs, the plaintext, IV, and ciphertext values shall be 128-bit blocks. The results from each test may either be obtained by the validator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

    To test the encrypt functionality, the evaluator shall supply a set of 10 plaintext values and obtain the ciphertext value that results from encryption of the given plaintext using a key value of all zeros and an IV of all zeros. Five plaintext values shall be encrypted with a 128-bit all zeros key, and the other five shall be encrypted with a 256-bit all zeros key. To test the decrypt functionality, the evaluator shall perform the same test as for encrypt, using 10 ciphertext values as input.

    To test the encrypt functionality, the evaluator shall supply a set of 10 key values and obtain the ciphertext value that results from encryption of an all zeros plaintext using the given key value and an IV of all zeros. Five of the key values shall be 128-bit keys, and the other five shall be 256-bit keys. To test the decrypt functionality, the evaluator shall perform the same test as for encrypt, using an all zero ciphertext value as input.

    To test the encrypt functionality, the evaluator shall supply the two sets of key values described below and obtain the ciphertext values that result from AES encryption of an all zeros plaintext using the given key values an an IV of all zeros. The first set of keys shall have 128 128-bit keys, and the second shall have 256 256-bit keys. Key_i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i in [1, N]. To test the decrypt functionality, the evaluator shall supply the two sets of key and ciphertext value pairs described below and obtain the plaintext value that results from decryption of the given ciphertext using the given key values and an IV of all zeros. The first set of key/ciphertext pairs shall have 128 128-bit key/ciphertext pairs, and the second set of key/ciphertext pairs shall have 256 256-bit pairs. Key_i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros for i in [1, N]. The ciphertext value in each pair shall be the value that results in an all zeros plaintext when decrypted with its corresponding key.

    To test the encrypt functionality, the evaluator shall supply the set of 128 plaintext values described below and obtain the two ciphertext values that result from encryption of the given plaintext using a 128-bit key value of all zeros and using a 256 bit key value of all zeros, respectively, and an IV of all zeros. Plaintext value i in each set shall have the leftmost bits be ones and the rightmost 128-i bits be zeros, for i in [1, 128]. To test the decrypt functionality, the evaluator shall perform the same test as for encrypt, using ciphertext values of the same form as the plaintext in the encrypt test as input.

    Test 2: Multi-Block Message Test

    The evaluator shall test the encrypt functionality by encrypting an i-block message where 1 less-than i less-than-or-equal to 10. For each i the evaluator shall choose a key, IV, and plaintext message of length i blocks and encrypt the message, using the mode to be tested, with the chosen key. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation. The evaluator shall also test the decrypt functionality by decrypting an i-block message where 1 less-than i less-than-or-equal to 10. For each i the evaluator shall choose a key and a ciphertext message of length i blocks and decrypt the message, using the mode to be tested, with the chosen key. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key using a known good implementation.

    Test 3: Monte-Carlo Test

    For AES-CTR mode perform the Monte Carlo Test for ECB Mode on the encryption engine of the counter mode implementation. There is no need to test the decryption engine.

    The evaluator shall test the encrypt functionality using 200 plaintext/key pairs. 100 of these shall use 128 bit keys, and 100 of these shall use 256 bit keys. The plaintext values shall be 128-bit blocks. For each pair, 1000 iterations shall be run as follows:

    For AES-ECB mode # Input: PT, Key for i = 1 to 1000: CT[i] = AES-ECB-Encrypt(Key, PT) PT = CT[i]

    The ciphertext computed in the 1000th iteration is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation.

    FCS_COP.1/Hash Cryptographic Operation - Hashing

    The inclusion of this selection-based component depends upon selection in FTP_DIT_EXT.1.1.
    FCS_COP.1.1/Hash
    The application shall perform cryptographic hashing services in accordance with a specified cryptographic algorithm [selection: ] and message digest sizes [selection: ] bits that meet the following: FIPS Pub 180-4.
    Application Note: This is dependent on implementing cryptographic functionality, as in FTP_DIT_EXT.1.

    Per NIST SP 800-131A, SHA-1 for generating digital signatures is no longer allowed, and SHA-1 for verification of digital signatures is strongly discouraged as there may be risk in accepting these signatures.

    SHA-1 is currently included in order to comply with the TLS. If the TLS package is included in the ST, the hashing algorithms selection for FCS_COP.1/Hash must match the hashing algorithms used in the mandatory and selected cipher suites of the TLS package. Vendors are strongly encouraged to implement updated protocols that support the SHA-2 family; until updated protocols are supported, this PP allows support for SHA-1 implementations in compliance with SP 800-131A.

    The intent of this requirement is to specify the hashing function. The hash selection must support the message digest size selection. The hash selection should be consistent with the overall strength of the algorithm used (for example, SHA 256 for 128-bit keys).
    Evaluation Activities
    FCS_COP.1/Hash
    TSS
    The evaluator shall check that the association of the hash function with other application cryptographic functions (for example, the digital signature verification function) is documented in the TSS.

    Guidance
    None.

    Tests
    The TSF hashing functions can be implemented in one of two modes. The first mode is the byte-oriented mode. In this mode the TSF hashes only messages that are an integral number of bytes in length; i.e., the length (in bits) of the message to be hashed is divisible by 8. The second mode is the bit-oriented mode. In this mode the TSF hashes messages of arbitrary length. As there are different tests for each mode, an indication is given in the following sections for the bit-oriented vs. the byte-oriented testmacs. The evaluator shall perform all of the following tests for each hash algorithm implemented by the TSF and used to satisfy the requirements of this PP.

    The following tests require the developer to provide access to a test application that provides the evaluator with tools that are typically not found in the production application.

    FCS_COP.1/KeyedHash Cryptographic Operation - Keyed-Hash Message Authentication

    The inclusion of this selection-based component depends upon selection in FTP_DIT_EXT.1.1.
    FCS_COP.1.1/KeyedHash
    The application shall perform keyed-hash message authentication in accordance with a specified cryptographic algorithm and [selection: ] with key sizes [assignment: key size (in bits) used in HMAC] and message digest sizes 256 and [selection: 160, 384, 512, no other size] bits that meet the following: FIPS Pub 198-1 The Keyed-Hash Message Authentication Code and FIPS Pub 180-4 Secure Hash Standard.
    Application Note: This is dependent on implementing cryptographic functionality, as in FTP_DIT_EXT.1.

    The intent of this requirement is to specify the keyed-hash message authentication function used for key establishment purposes for the various cryptographic protocols used by the application (e.g., trusted channel). The hash selection must support the message digest size selection. The hash selection should be consistent with the overall strength of the algorithm used for FCS_COP.1/SKC.
    Evaluation Activities
    FCS_COP.1/KeyedHash
    The evaluator shall perform the following activities based on the selections in the ST.
    TSS
    None.

    Guidance
    None.

    Tests
    For each of the supported parameter sets, the evaluator shall compose 15 sets of test data. Each set shall consist of a key and message data. The evaluator shall have the TSF generate HMAC tags for these sets of test data. The resulting MAC tags shall be compared to the result of generating HMAC tags with the same key and IV using a known-good implementation.

    FCS_COP.1/Sig Cryptographic Operation - Signing

    The inclusion of this selection-based component depends upon selection in FTP_DIT_EXT.1.1.
    FCS_COP.1.1/Sig
    The application shall perform cryptographic signature services (generation and verification) in accordance with a specified cryptographic algorithm [selection: ].
    Application Note: This is dependent on implementing cryptographic functionality, as in FTP_DIT_EXT.1.

    The ST Author should choose the algorithm implemented to perform digital signatures; if more than one algorithm is available, this requirement should be iterated to specify the functionality. For the algorithm chosen, the ST author should make the appropriate assignments/selections to specify the parameters that are implemented for that algorithm.
    Evaluation Activities
    FCS_COP.1/Sig
    The evaluator shall perform the following activities based on the selections in the ST.
    TSS
    None.

    Guidance
    None.

    Tests
    The following tests require the developer to provide access to a test application that provides the evaluator with tools that are typically not found in the production application.

    ECDSA Algorithm Tests RSA Signature Algorithm Tests

    FCS_HTTPS_EXT.1/Client HTTPS Protocol

    The inclusion of this selection-based component depends upon selection in FTP_DIT_EXT.1.1.
    FCS_HTTPS_EXT.1.1/Client
    The application shall implement the HTTPS protocol that complies with RFC 2818.
    FCS_HTTPS_EXT.1.2/Client
    The application shall implement HTTPS using TLS as defined in the Functional Package for TLS.
    FCS_HTTPS_EXT.1.3/Client
    The application shall [selection: not establish the application-initiated connection, notify the user and not establish the user-initiated connection, notify the user and request authorization to establish the user-initiated connection] if the peer certificate is deemed invalid.
    Application Note: Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280.
    Evaluation Activities
    FCS_HTTPS_EXT.1.1/Client
    TSS
    The evaluator shall examine the TSS and determine that enough detail is provided to explain how the implementation complies with RFC 2818.

    Guidance
    None.

    Tests
    The evaluator shall attempt to establish an HTTPS connection with a webserver, observe the traffic with a packet analyzer, and verify that the connection succeeds and that the traffic is identified as TLS or HTTPS.

    FCS_HTTPS_EXT.1.2/Client
    TSS
    None

    Guidance
    None.

    Tests
    Other tests are performed in conjunction with the TLS package.

    FCS_HTTPS_EXT.1.3/Client
    TSS
    None

    Guidance
    None.

    Tests
    Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1, and the evaluator shall perform the following test:

    FCS_HTTPS_EXT.1/Server HTTPS Protocol

    The inclusion of this selection-based component depends upon selection in FTP_DIT_EXT.1.1.
    FCS_HTTPS_EXT.1.1/Server
    The application shall implement the HTTPS protocol that complies with RFC 2818.
    FCS_HTTPS_EXT.1.2/Server
    The application shall implement HTTPS using TLS as defined in the Functional Package for TLS.
    Evaluation Activities
    FCS_HTTPS_EXT.1.1/Server
    TSS
    The evaluator shall examine the TSS and determine that enough detail is provided to explain how the implementation complies with RFC 2818.

    Guidance
    None.

    Tests
    The evaluator shall attempt to establish an HTTPS connection to the TOE using a client, observe the traffic with a packet analyzer, and verify that the connection succeeds and that the traffic is identified as TLS or HTTPS.

    FCS_HTTPS_EXT.1.2/Server
    TSS
    None

    Guidance
    None.

    Tests
    Other tests are performed in conjunction with the TLS package.

    FCS_HTTPS_EXT.2 HTTPS Protocol with Mutual Authentication

    The inclusion of this selection-based component depends upon selection in FTP_DIT_EXT.1.1.
    FCS_HTTPS_EXT.2.1
    The application shall [selection: not establish the connection, establish or not establish the connection based on an administrative or user setting]if the peer certificate is deemed invalid.
    Application Note: Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280.
    Evaluation Activities
    FCS_HTTPS_EXT.2.1
    TSS
    None.

    Guidance
    None.

    Tests
    Certificate validity shall be tested in accordance with testing performed for FIA_X509_EXT.1, and the evaluator shall perform the following test:

    FCS_RBG_EXT.2 Random Bit Generation from Application

    The inclusion of this selection-based component depends upon selection in FCS_RBG_EXT.1.1.
    FCS_RBG_EXT.2.1
    The application shall perform all deterministic random bit generation (DRBG) services in accordance with NIST Special Publication 800-90A using [selection: Hash_DRBG (any), HMAC_DRBG (any), CTR_DRBG (AES)]
    Application Note: This requirement shall be included in STs in which "implement DRBG functionality" is chosen in FCS_RBG_EXT.1.1. The ST author should select the standard to which the RBG services comply (either SP 800-90A or FIPS 140-2 Annex C).

    SP 800-90A contains three different methods of generating random numbers; each of these, in turn, depends on underlying cryptographic primitives (hash functions/ciphers). The ST author will select the function used (if SP 800-90A is selected), and include the specific underlying cryptographic primitives used in the requirement or in the TSS. While any of the identified hash functions (SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based implementations for CTR_DRBG are allowed.
    FCS_RBG_EXT.2.2
    The deterministic RBG shall be seeded by an entropy source that accumulates entropy from a platform-based DRBG and [selection: ] with a minimum of [selection: ] of entropy at least equal to the greatest security strength (according to NIST SP 800-57) of the keys and hashes that it will generate.
    Application Note: This requirement shall be included in STs in which "implement DRBG functionality" is chosen in FCS_RBG_EXT.1.1. For the first selection in this requirement, the ST author selects "software-based noise source" if any additional noise sources are used as input to the application's DRBG. Note that the application must use the platform's DRBG to seed its DRBG.

    In the second selection in this requirement, the ST author selects the appropriate number of bits of entropy that corresponds to the greatest security strength of the algorithms included in the ST. Security strength is defined in Tables 2 and 3 of NIST SP 800-57A. For example, if the implementation includes 2048-bit RSA (security strength of 112 bits) and AES 256 (security strength 256 bits), then the ST author would select 256 bits.
    Evaluation Activities
    FCS_RBG_EXT.2.1
    TSS
    None.

    Guidance
    None.

    Tests
    The evaluator shall perform the following tests, depending on the standard to which the RBG conforms.

    Implementations Conforming to FIPS 140-2 Annex C.

    The reference for the tests contained in this section is The Random Number Generator Validation System (RNGVS). The evaluators shall conduct the following two tests. Note that the "expected values" are produced by a reference implementation of the algorithm that is known to be correct. Proof of correctness is left to each Scheme. Implementations Conforming to NIST Special Publication 800-90A
    FCS_RBG_EXT.2.2
    TSS
    Documentation shall be produced - and the evaluator shall perform the activities - in accordance with Appendix C - Entropy Documentation and Assessment and the Clarification to the Entropy Documentation and Assessment Annex.

    Guidance
    None.

    Tests
    In the future, specific statistical testing (in line with NIST SP 800-90B) will be required to verify the entropy estimates.

    B.2 Identification and Authentication (FIA)

    FIA_X509_EXT.1 X.509 Certificate Validation

    The inclusion of this selection-based component depends upon selection in FTP_DIT_EXT.1.1.
    FIA_X509_EXT.1.1
    The application shall [selection: invoke platform-provided functionality, implement functionality] to validate certificates in accordance with the following rules:
    Application Note: FIA_X509_EXT.1.1 lists the rules for validating certificates. The ST author shall select whether revocation status is verified using OCSP or CRLs. FIA_X509_EXT.2 requires that certificates are used for HTTPS, TLS, and DTLS; this use requires that the extendedKeyUsage rules are verified. If OCSP is not supported the EKU provision for checking the OCSP Signing purpose is met by default.

    This requirement is included if the protocol(s) selected in FTP_DIT_EXT.1.1 require the use of certificates. If the TOE implements TLS as a HTTPS/TLS server with no mutual authentication, this requirement is not applicable.

    OCSP stapling and OCSP multi-stapling only support TLS server certificate validation. If other certificate types are validated, either OCSP or CRL should be claimed.

    Regardless of the selection of "implement functionality or invoke platform-provided functionality," the validation is expected to end in a trusted root CA certificate in a root store managed by the platform.
    FIA_X509_EXT.1.2
    The application shall treat a certificate as a CA certificate only if the basicConstraints extension is present and the CA flag is set to TRUE.
    Application Note: This requirement applies to certificates that are used and processed by the TSF and restricts the certificates that may be added as trusted CA certificates.
    Evaluation Activities
    FIA_X509_EXT.1.1
    TSS
    The evaluator shall ensure the TSS describes where the check of validity of the certificates takes place. The evaluator ensures the TSS also provides a description of the certificate path validation algorithm.

    Guidance
    None.

    Tests
    The tests described must be performed in conjunction with the other certificate services evaluation activities, including the functions in FIA_X509_EXT.2.1. The tests for the extendedKeyUsage rules are performed in conjunction with the uses that require those rules. If the application supports chains of length four or greater, the evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. If the application supports a maximum trust depth of two, then a chain with no Intermediate CA should instead be created.
    FIA_X509_EXT.1.2
    TSS
    None.

    Guidance
    None.

    Tests
    The tests described must be performed in conjunction with the other certificate services evaluation activities, including the functions in FIA_X509_EXT.2.1. If the application supports chains of length four or greater, the evaluator shall create a chain of at least four certificates: the node certificate to be tested, two Intermediate CAs, and the self-signed Root CA. If the application supports a maximum trust depth of two, then a chain with no Intermediate CA should instead be created. FIA_X509_EXT.2 X.509 Certificate Authentication
    section of the ST describes the process for decrypting Enterprise application data and shared resource data. The evaluator shall ensure that this process requires the user to enter an Authentication Factor and, in accordance with FCS_CKM_EXT.3, derives a KEK which is used to protect the software-based secure key storage and (optionally) DEKs for sensitive data, in accordance with FCS_STG_EXT.2.


    Guidance
    There are no guidance evaluation activities for this element.


    Tests
    There are no test evaluation activities for this element.


    A.2 Objective Requirements

    A.2.1 Class: Security Audit (FAU)

    FAU_SEL.1 Selective Audit

    The TSF shall be able to select the set of events to be audited from the set of all auditable events based on the following attributes:[selection: [event type], [success of auditable security events, failure of auditable security events, [assignment: other attributes ], ]].
    Application Note: The intent of this requirement is to identify all criteria that can be selected to trigger an audit event. This can be configured through an interface on the TSF for a user or administrator to invoke. For the ST author, the assignment is used to list any additional criteria or "none".
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    The evaluator shall review the administrative guidance to ensure that the guidance itemizes all event types, as well as describes all attributes that are to be selectable in accordance with the requirement, to include those attributes listed in the assignment. The administrative guidance shall also contain instructions on how to set the pre-selection as well as explain the syntax (if present) for multi-value pre-selection. The administrative guidance shall also identify those audit records that are always recorded, regardless of the selection criteria currently being enforced.


    Tests
    • Test FAU_SEL.1.1:1: For each attribute listed in the requirement, the evaluator shall devise a test to show that selecting the attribute causes only audit events with that attribute (or those that are always recorded, as identified in the administrative guidance) to be recorded.
    • Test FAU_SEL.1.1:2: [conditional] If the TSF supports specification of more complex audit pre-selection criteria (e.g., multiple attributes, logical expressions using attributes) then the evaluator shall devise tests showing that this capability is correctly implemented. The evaluator shall also, in the test plan, provide a short narrative justifying the set of tests as representative and sufficient to exercise the capability.

    A.2.2 Class: Cryptographic Support (FCS)

    FCS_RBG_EXT.2 Random Bit Generator State Preservation

    The TSF shall save the state of the deterministic RBG at power-off, and shall use this state as input to the deterministic RBG at startup.
    Application Note: The capability to add the state saved at power-off as input to the RBG prevents an RBG that is slow to gather entropy from producing the same output regularly and across reboots. Since there is no guarantee of the protections provided when the state is stored (or a requirement for any such protection), it is assumed that the state is 'known', and therefore cannot contribute entropy to the RBG, but can introduce enough variation that the initial RBG values are not predictable and exploitable.
    TSS
    The evaluation activity for this requirement is captured in the RBG documentation for Appendix D - Entropy Documentation And Assessment. The evaluator shall verify that the documentation describes how the state is generated so as to be available for the next startup, how the state is used as input to the DRBG, and any protection measures used for the state while the TOE is powered off.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    FCS_RBG_EXT.3 Support for Personalization String

    The TSF shall allow applications to add data to the deterministic RBG using the Personalization String as defined in SP 800-90A.
    Application Note: As specified in SP 800-90A, the TSF must not count data input from an application towards the entropy required by FCS_RBG_EXT.1. Thus, the TSF must not allow the only input to the RBG seed to be from an application.
    The evaluator shall verify that this function is included as an interface to the RBG in the documentation required by and that the behavior of the RBG following a call to this interface is described. The evaluator shall also verify that the documentation of the RBG describes the conditions of use and possible values for the Personalization String input to the SP 800-90A specified DRBG.
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    • Test FCS_RBG_EXT.3.1:1: The evaluator shall write, or the developer shall provide, an application that adds data to the RBG via the Personalization String. The evaluator shall verify that the request succeeds.

    FCS_SRV_EXT.2 Cryptographic Key Storage Services

    The TSF shall provide a mechanism for applications to request the TSF to perform the following cryptographic operations: [ ] by keys stored in the secure key storage.
    Application Note: The TOE will, therefore, be required to perform cryptographic operations on behalf of applications using the keys stored in the TOE’s secure key storage.
    The evaluator shall verify that the API documentation for the secure key storage includes the cryptographic operations by the stored keys.
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    The evaluator shall write, or the developer shall provide access to, an application that requests cryptographic operations of stored keys by the TSF. The evaluator shall verify that the results from the operation match the expected results according to the API documentation. The evaluator shall use these APIs to test the functionality of the secure key storage according to the Evaluation Activities in FCS_STG_EXT.1.

    A.2.3 Class: User Data Protection (FDP)

    FDP_ACF_EXT.3 Security Attribute Based Access Control

    The TSF shall enforce an access control policy that prohibits an application from granting both write and execute permission to a file on the device except for[selection: files stored in the application's private data folder, no exceptions].
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    • Test FDP_ACF_EXT.3.1:1: The evaluator shall write, or the developer shall provide, an application that attempts to store a file with both write and execute permissions. If the selection is "no exceptions", then the evaluator shall verify that this action fails and that the permissions on the file are not simultaneously write and execute. If the selection is "application's private data folder", then the evaluator shall ensure that the attempt to store the file is outside of the application's private data folder.
    • Test FDP_ACF_EXT.3.1:2: The evaluator shall traverse the file system examining the permission on each TSF file to verify that no file has both write and execute permissions set. If the selection is "application's private data folder", then only files outside of this folder need to be examined by the evaluator for this test.

    FDP_BCK_EXT.1 Application Backup

    The TSF shall provide a mechanism for applications to mark[selection: all application data, selected application data]to be excluded from device backups.
    Application Note: Device backups include any mechanism built into the TOE that allows stored application data to be extracted over a physical port or sent over the network, but does not include any functionality implemented by a specific application itself if the application is not included in the TOE. The lack of a public/documented API for performing backups, when a private/undocumented API exists, is not sufficient to meet this requirement.
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    If all application data is selected, the evaluator shall install an application that has marked all of its application data to be excluded from backups. The evaluator shall cause data to be placed into the application’s storage area. The evaluator shall attempt to back up the application data and verify that the backup fails or that the application’s data was not included in the backup.


    If selected application data is selected, the evaluator shall install an application that has marked selected application data to be excluded from backups. The evaluator shall cause data covered by "selected application data" to be placed into the application’s storage area. The evaluator shall attempt to backup that selected application data and verify that either the backup fails or that the selected data is excluded from the backup.

    FDP_BLT_EXT.1 Limitation of Bluetooth Device Access

    The TSF shall limit the applications that may communicate with a particular paired Bluetooth device.
    Application Note: Not every application with privileges to use Bluetooth should be permitted to communicate with every paired Bluetooth device. For example, the TSF may choose to require that only the application that initiated the current connection may communicate with the device, or it may strictly tie the paired device to the first application that makes a socket connection to the device following initial pairing. Additionally, for more flexibility, the TSF may choose to provide the user with a way to select which applications on the device may communicate with or observe communications with each paired Bluetooth device.
    TSS
    The evaluator shall ensure that the TSS describes the mechanism used to prevent unrestricted access to paired Bluetooth devices (or their communication data) by every application with access to the Bluetooth system service on the TOE. The evaluator shall verify that this method either restricts access to a single application or provides explicit control of the applications that may communicate with the paired Bluetooth device.


    Guidance
    The evaluator shall verify that the AGD contains the steps to configure which applications are allowed to communicate with a given Bluetooth peripheral.


    Tests
    The evaluator shall establish a Bluetooth connection with any peripheral. The evaluator shall verify that an application that is allowed to communicate with the Bluetooth peripheral is able to and that an application that is not allowed to communicate with that Bluetooth peripheral is unable to communicate with the peripheral.

    A.2.4 Class: Identification and Authentication (FIA)

    FIA_X509_EXT.4 X509 Certificate Enrollment

    The TSF shall use the Enrollment over Secure Transport (EST) protocol as specified in RFC 7030 to request certificate enrollment using the simple enrollment method described in RFC 7030 Section 4.2.
    The TSF shall be capable of authenticating EST requests using an existing certificate and corresponding private key as specified by RFC 7030 Section 3.3.2.
    The TSF shall be capable of authenticating EST requests using HTTP Basic Authentication with a username and password as specified by RFC 7030 Section 3.2.3.
    The TSF shall perform authentication of the EST server using an Explicit Trust Anchor following the rules described in RFC 7030, section 3.6.1.
    Application Note: EST also uses HTTPS as specified in FCS_HTTPS_EXT.1 to establish a secure connection to an EST server. The separate Trust Anchor Database dedicated to EST operations is described as Explicit Trust Anchors in RFC 7030.
    The TSF shall be capable of requesting server-provided private keys as specified in RFC 7030 Section 4.4.
    The TSF shall be capable of updating its EST-specific Trust Anchor Database using the "Root CA Key Update" process described in RFC 7030 Section 4.1.3.
    The TSF shall generate a Certificate Request Message for EST as specified in RFC 2986 and be able to provide the following information in the request: public key and[selection: device-specific information, Common Name, Organization, Organizational Unit, Country].
    Application Note: The public key referenced is the public key portion of the public-private key pair generated by the TOE as specified in FCS_CKM.1.
    The TSF shall validate the chain of certificates from the Root CA certificate in the Trust Anchor Database to the EST Server CA certificate upon receiving a CA Certificates Response.
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    The evaluator shall check to ensure that the operational guidance contains instructions on requesting certificates from an EST server, including generating a Certificate Request Message.


    Tests
    • Test FIA_X509_EXT.4.8:1: The evaluator shall use the operational guidance to cause the TOE to request certificate enrollment from an EST server using the simple enrollment method described in RFC 7030 Section 4.2, authenticating the certificate request to the server using an existing certificate and private key as described by RFC 7030 Section 3.3.2. The evaluator shall confirm that the resulting certificate is successfully obtained and installed in the TOE key store.
    • Test FIA_X509_EXT.4.8:2: The evaluator shall use the operational guidance to cause the TOE to request certificate enrollment from an EST server using the simple enrollment method described in RFC 7030 Section 4.2, authenticating the certificate request to the server using a username and password as described by RFC 7030 Section 3.2.3. The evaluator shall confirm that the resulting certificate is successfully obtained and installed in the TOE key store.
    • Test FIA_X509_EXT.4.8:3: The evaluator shall modify the EST server to return a certificate containing a different public key than the key included in the TOE’s certificate request. The evaluator shall use the operational guidance to cause the TOE to request certificate enrollment from an EST server. The evaluator shall confirm that the TOE does not accept the resulting certificate since the public key in the issued certificate does not match the public key in the certificate request.
    • Test FIA_X509_EXT.4.8:4: The evaluator shall configure the EST server or use a man-in-the-middle tool to present a server certificate to the TOE that is present in the TOE general Trust Anchor Database but not its EST-specific Trust Anchor Database. The evaluator shall cause the TOE to request certificate enrollment from the EST server. The evaluator shall verify that the request is not successful.
    • Test FIA_X509_EXT.4.8:5: The evaluator shall configure the EST server or use a man-in-the-middle tool to present an invalid certificate. The evaluator shall cause the TOE to request certificate enrollment from the EST server. The evaluator shall verify that the request is not successful The evaluator shall configure the EST server or use a man-in-the-middle tool to present a certificate that does not have the CMC RA purpose and verify that requests to the EST server fail. The tester shall repeat the test using a valid certificate and a certificate that contains the CMC RA purpose and verify that the certificate enrollment requests succeed.
    • Test FIA_X509_EXT.4.8:6: The evaluator shall use a packet sniffing tool between the TOE and an EST server. The evaluator shall turn on the sniffing tool and cause the TOE to request certificate enrollment from an EST server. The evaluator shall verify that the EST protocol interaction occurs over a Transport Layer Security (TLS) protected connection. The evaluator is not expected to decrypt the connection but rather observe that the packets conform to the TLS protocol format.
    • Test FIA_X509_EXT.4.8:7: The evaluator shall use the operational guidance to cause the TOE to request a server-provided private key and certificate from an EST server. The evaluator shall confirm that the resulting private key and certificate are successfully obtained and installed in the TOE key store.
    • Test FIA_X509_EXT.4.8:8: The evaluator shall modify the EST server to, in response to a server-provided private key and certificate request, return a private key that does not correspond with the public key in the returned certificate. The evaluator shall use the operational guidance to cause the TOE to request a server-provided private key and certificate. The evaluator shall confirm that the TOE does not accept the resulting private key and certificate since the private key and public key do not correspond.
    • Test FIA_X509_EXT.4.8:9: The evaluator shall configure the EST server to provide a "Root CA Key Update" as described in RFC 7030 Section 4.1.3. The evaluator shall cause the TOE to request CA certificates from the EST server and shall confirm that the EST-specific Trust Anchor Database is updated with the new trust anchor.
    • Test FIA_X509_EXT.4.8:10: The evaluator shall configure the EST server to provide a "Root CA Key Update" as described in RFC 7030 Section 4.1.3, but shall modify part of the NewWithOld certificate’s generated signature. The evaluator shall cause the TOE to request CA certificates from the EST server and shall confirm that the EST-specific Trust Anchor Database is not updated with the new trust anchor since the signature did not verify.
    • Test FIA_X509_EXT.4.8:11: The evaluator shall use the operational guidance to cause the TOE to generate a certificate request message. The evaluator shall capture the generated message and ensure that it conforms to the format specified by RFC 2986. The evaluator shall confirm that the certificate request provides the public key and other required information, including any necessary user-input information.

    FIA_X509_EXT.5 X.509 Certificate Requests

    The TSF shall generate a Certificate Request Message as specified in RFC 2986 and be able to provide the following information in the request: public key and[selection: device-specific information, Common Name, Organization, Organizational Unit, Country].
    Application Note: The public key referenced in FIA_X509_EXT.5.1 is the public key portion of the public-private key pair generated by the TOE as specified in FCS_CKM.1. The trusted channel requirements do not apply to communication with the CA for the certificate request/response messages.


    As Enrollment over Secure Transport (EST) is a new standard that has not yet been widely adopted, this requirement is included as an interim objective requirement in order to allow developers to distinguish those products which have do have the ability to generate Certificate Request Messages but do not yet implement EST.
    The TSF shall validate the chain of certificates from the Root CA upon receiving the CA Certificate Response.
    TSS
    If the ST author selects "device-specific information", the evaluator shall verify that the TSS contains a description of the device-specific fields used in certificate requests.


    Guidance
    The evaluator shall check to ensure that the operational guidance contains instructions on generating a Certificate Request Message. If the ST author selects "Common Name", "Organization", "Organizational Unit", or "Country", the evaluator shall ensure that this guidance includes instructions for establishing these fields before creating the certificate request message.


    Tests
      The evaluator shall also perform the following tests:
    • Test FIA_X509_EXT.5.2:1: The evaluator shall use the operational guidance to cause the TOE to generate a certificate request message. The evaluator shall capture the generated message and ensure that it conforms to the format specified. The evaluator shall confirm that the certificate request provides the public key and other required information, including any necessary user-input information.
    • Test FIA_X509_EXT.5.2:2: The evaluator shall demonstrate that validating a certificate response message without a valid certification path results in the function failing. The evaluator shall then load a certificate or certificates as trusted CAs needed to validate the certificate response message, and demonstrate that the function succeeds. The evaluator shall then delete one of the certificates, and show that the function fails.

    A.2.5 Class: Security Management (FMT)

    FMT_SMF_EXT.3 Current Administrator

    The TSF shall provide a mechanism that allows users to view a list of currently authorized administrators and the management functions that each administrator is authorized to perform.
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    The evaluator shall cause the TOE to be enrolled into management. The evaluator shall then invoke this mechanism and verify the ability to view that the device has been enrolled, and view the management functions that the administrator is authorized to perform.

    A.2.6 Class: Protection of the TSF (FPT)

    FPT_AEX_EXT.5 Kernel Address Space Layout Randomization

    The TSF shall provide address space layout randomization (ASLR) to the kernel.
    The base address of any kernel-space memory mapping will consist of[assignment: number greater than or equal to 4]unpredictable bits.
    Application Note: The unpredictable bits may be provided by the TSF RBG (as specified in FCS_RBG_EXT.1).
    TSS
    The evaluator shall ensure that the TSS section of the ST describes how the bits are generated and provides a justification as to why those bits are unpredictable.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
      The following test require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on consumer Mobile Device products.
    • Test FPT_AEX_EXT.5.2:1: The evaluator shall reboot the TOE six times. For each of these reboots, the evaluator shall examine memory mapping locations of the kernel. The evaluator must ensure that for at least five reboots the memory mappings are not placed in the same location on both devices.

    FPT_AEX_EXT.6 Write or Execute Memory Page Permissions

    The TSF shall prevent write and execute permissions from being simultaneously granted to any page of physical memory[selection: with no exceptions, [assignment: specific exceptions ]].
    Application Note: Memory used for just-in-time (JIT) compilation is anticipated as an exception in this requirement; if so, the ST author must address how this exception is permitted. It is expected that the memory management unit will transition the system to a non-operational state if any violation is detected in kernel memory space.
    TSS
    The evaluator shall ensure that the TSS describes how the operating system of the application processor prevents all processes executing in a non-privileged execution domain from achieving write and execute permissions on any page of memory (with only specified exceptions). The evaluator shall ensure that the TSS describes how such processes are unable to request pages of memory with such permissions, and how they are unable to change permissions to both write and execute on any pages already allocated to them.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    FPT_AEX_EXT.7 Heap Overflow Protection

    The TSF shall include heap-based buffer overflow protections in the runtime environment it provides to processes that execute on the application processor.
    Application Note: These heap-based buffer overflow protections are expected to ensure the integrity of heap metadata such as memory addresses or offsets recorded by the heap implementation to manage memory blocks. This includes chunk headers, look-aside lists, and other data structures used to track the state and location of memory blocks managed by the heap.
    TSS
    The evaluator shall verify that the TSS enumerates the heap implementations provided to userspace processes. The evaluator shall ensure that the TSS lists all types of heap metadata and identifies how the integrity of each type of metadata is ensured. The evaluator shall ensure that the TSS identifies all fields within each type of metadata and identifies how the integrity of these fields is ensured. The evaluator shall verify that the TSS identifies the manner in which an error condition is entered when a heap overflow is detected and the resulting actions taken by the TSF.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    For each heap implementation, the evaluator shall write, or the developer shall provide access to, an application, which allocates memory from the heap and then writes arbitrary data significantly beyond the end of the allocated buffer. The evaluator shall attempt to execute this application and verify that the write is not allowed.

    FPT_BBD_EXT.1 Application Processor Mediation

    The TSF shall prevent code executing on any baseband processor (BP) from accessing application processor (AP) resources except when mediated by the AP.
    Application Note: These resources include:

    • Volatile and non-volatile memory
    • Control of and data from integrated and non-integrated peripherals (e.g. USB controllers, touch screen controllers, LCD controller, codecs)
    • Control of and data from integrated and non-integrated I/O sensors (e.g. camera, light, microphone, GPS, accelerometers, geomagnetic field sensors)

    Mobile devices are becoming increasingly complex having an application processor that runs an operating system and user applications and separate baseband processors that handle cellular and other wireless network connectivity.


    • The application processor within most modern Mobile Devices is a system on a chip (SoC) that integrates, for example, CPU/GPU cores and memory interface electronics into a single, power-efficient package.
    • Baseband processors are becoming increasingly complex themselves delivering voice encoding alongside multiple independent radios (LTE, Wi-Fi, Bluetooth, FM, GPS) in a single package containing multiple CPUs and DSPs.

    Thus, the baseband processors in these requirements include such integrated SoCs and include any radio processors (integrated or not) on the Mobile Device.


    All other requirements mostly, except where noted, apply to firmware/software on the application processor, but future requirements (notably, all Integrity, Access Control, and Anti-Exploitation requirements) will apply to application processors and baseband processors.
    TSS
    The evaluator shall ensure that the TSS section of the ST describes at a high level how the processors on the Mobile Device interact, including which bus protocols they use to communicate, any other devices operating on that bus (peripherals and sensors), and identification of any shared resources. The evaluator shall verify that the design described in the TSS does not permit any BPs from accessing any of the peripherals and sensors or from accessing main memory (volatile and non-volatile) used by the AP. In particular, the evaluator shall ensure that the design prevents modification of executable memory of the AP by the BP.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    FPT_BLT_EXT.1 Limitation of Bluetooth Profile Support

    The TSF shall disable support for[assignment: list of Bluetooth profiles]Bluetooth profiles when they are not currently being used by an application on the Mobile Device, and shall require explicit user action to enable them.
    Application Note: Some Bluetooth services incur more serious consequences if unauthorized remote devices gain access to them. Such services should be protected by measures like disabling support for the associated Bluetooth profile unless it is actively being used by an application on the Mobile Device (in order to prevent discovery by a Service Discovery Protocol search), and then requiring explicit user action to enable those profiles in order to use the services. It may be further appropriate to require additional user action before granting a remote device access to that service.


    For example, it may be appropriate to disable the OBEX Push Profile until a user on the Mobile Device pushes a button in an application indicating readiness to transfer an object. After completion of the object transfer, support for the OBEX profile should be suspended until the next time the user requests its use.
    TSS
    The evaluator shall ensure that the TSS lists all Bluetooth profiles that are disabled while not in use by an application and which need explicit user action in order to become enabled.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
      The evaluator shall perform the following tests:
    • Test FPT_BLT_EXT.1.1:1: While the service is not in active use by an application on the TOE, the evaluator shall attempt to discover a service associated with a "protected" Bluetooth profile (as specified by the requirement) on the TOE via a Service Discovery Protocol search. The evaluator shall verify that the service does not appear in the Service Discovery Protocol search results. Next, the evaluator shall attempt to gain remote access to the service from a device that does not currently have a trusted device relationship with the TOE. The evaluator shall verify that this attempt fails due to the unavailability of the service and profile.
    • Test FPT_BLT_EXT.1.1:2: The evaluator shall repeat Test 1 with a device that currently has a trusted device relationship with the TOE and verify that the same behavior is exhibited.

    FPT_NOT_EXT.2 Software Integrity Verification

    The TSF shall[selection: audit, provide the administrator with]TSF-software integrity verification values.
    Application Note: These notifications are typically called remote attestation and these integrity values are typically called measurements. The integrity values are calculated from hashes of critical memory and values, including executable code. The ST author must select whether these values are logged as a part of FAU_GEN.1.1 or are provided to the administrator.
    The TSF shall cryptographically sign all integrity verification values.
    Application Note: The intent of this requirement is to provide assurance to the administrator that the responses provided are from the TOE and have not been modified or spoofed by a man-in-the-middle such as a network-based adversary or a malicious MDM Agent.
    TSS
    The evaluator shall verify that the TSS describes which critical memory is measured for these integrity values and how the measurement is performed (including which TOE software performs these generates these values, how that software accesses the critical memory, and which algorithms are used).


    Guidance
    If the integrity values are provided to the administrator, the evaluator shall verify that the AGD guidance contains instructions for retrieving these values and information for interpreting them. For example, if multiple measurements are taken, what those measurements are and how changes to those values relate to changes in the device state.


    Tests
      The evaluator shall repeat the following test for each measurement:
    • Test FPT_NOT_EXT.2.1:1: The evaluator shall boot the device in an approved state and record the measurement taken (either from the log or by using the administrative guidance to retrieve the value via an MDM Agent). The evaluator shall modify the critical memory or value that is measured. The evaluator shall boot the device and verify that the measurement changed.
    TSS
    The evaluator shall verify that the TSS describes which key the TSF uses to sign the responses to queries and the certificate used to prove ownership of the key, and the method of associating the certificate with a particular device manufacturer and model.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
      The evaluator shall perform the following test:
    • Test FPT_NOT_EXT.2.2:1: The evaluator shall write, or the developer shall provide, a management application that queries either the audit logs or the measurements. The evaluator shall verify that the responses to these queries are signed and verify the signatures against the TOE’s certificate.

    FPT_TST_EXT.2/POSTKERNEL TSF Integrity Checking (Post-Kernel)

    The TSF shall verify the integrity of[selection: all executable code, [assignment: subset of executable code ]]stored in mutable media prior to its execution through the use of[selection: a digital signature using an immutable hardware asymmetric key, an immutable hardware hash of an asymmetric key, an immutable hardware hash, a digital signature using a hardware-protected asymmetric key, hardware-protected hash].
    Application Note: All executable code covered in this requirement is executed after the kernel is loaded.


    If "all executable code in mutable media" is verified, implementation in hardware or in read-only memory is a natural logical consequence.


    At this time, the verification of software executed on other processors stored in mutable media is not required; however, it may be added in the first assignment. If all executable code (including bootloaders, kernel, device drivers, pre-loaded applications, user-loaded applications, and libraries) is verified, "all executable code stored in mutable media" should be selected.
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    The evaluation activity shall be completed in conjunction with FPT_TST_EXT.2/PREKERNEL for all executable code specified.

    FPT_TUD_EXT.5 Application Verification

    The TSF shall by default only install mobile applications cryptographically verified by[selection: a built-in X.509v3 certificate, a configured X.509v3 certificate].
    Application Note: The built-in certificate is installed by the manufacturer either at time of manufacture or as a part of system updates. The configured certificate used to verify the signature is set according to FMT_SMF.1 function 33.
    TSS
    The evaluator shall verify that the TSS describes how mobile application software is verified at installation. The evaluator shall ensure that this method uses a digital signature by a code signing certificate.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    • Test FPT_TUD_EXT.5.1:1: The evaluator shall write, or the developer shall provide access to, an application. The evaluator shall try to install this application without a digitally signature and shall verify that installation fails. The evaluator shall attempt to install an application digitally signed with an appropriate certificate, and verify that installation succeeds.
    • Test FPT_TUD_EXT.5.1:2: The evaluator shall digitally sign the application with an invalid certificate and verify that application installation fails. The evaluator shall digitally sign the application with a certificate that does not have the Code Signing purpose and verify that application installation fails. This test may be performed in conjunction with the Evaluation Activities for FIA_X509_EXT.1.
    • Test FPT_TUD_EXT.5.1:3: If necessary, the evaluator shall configure the device to limit the public keys that can sign application software according to the AGD guidance. The evaluator shall digitally sign the application with a certificate disallowed by the device or configuration and verify that application installation fails. The evaluator shall attempt to install an application digitally signed with an authorized certificate and verify that application installation succeeds.

    FPT_TUD_EXT.6 Trusted Update Verification

    The TSF shall verify that software updates to the TSF are a current or later version than the current version of the TSF.
    Application Note: A later version has a larger version number. The method for distinguishing newer software versions from older versions is determined by the manufacturer.
    TSS
    The evaluator shall verify that the TSS describes the mechanism that prevents the TSF from installing software updates that are an older version that the currently installed version.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
      The evaluator shall repeat the following tests to cover all allowed software update mechanisms as described in the TSS. For example, if the update mechanism replaces an entire partition containing many separate code files, the evaluator does not need to repeat the test for each individual file.
    • Test FPT_TUD_EXT.6.1:1: The evaluator shall attempt to install an earlier version of software (as determined by the manufacturer). The evaluator shall verify that this attempt fails by checking the version identifiers or cryptographic hashes of the privileged software against those previously recorded and checking that the values have not changed.
    • Test FPT_TUD_EXT.6.1:2: The evaluator shall attempt to install a current or later version and shall verify that the update succeeds.

    A.3 Implementation-dependent Requirements

    This PP does not define any Implementation-dependent requirements.

    Appendix B - Selection-based Requirements

    As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the TOE or its underlying platform) are contained in the body of this PP. There are additional requirements based on selections in the body of the PP: if certain selections are made, then additional requirements below must be included.

    B.1 Class: Cryptographic Support (FCS)

    FCS_CKM_EXT.7 Cryptographic Key Support (REK)

    The inclusion of this selection-based component depends upon selection in
    FTP
    FCS_
    DIT
    CKM_EXT.1.1.
    FIA
    X509
    2
    7.1
    The application shall use X.509v3 certificates as defined by RFC 5280 to support authentication for [selection: HTTPS, TLS, DTLS, SSH, IPsec]FTP_DIT
    A REK shall not be able to be read from or exported from the hardware.
    Application Note:
    This requirement is included if the protocol(s) selected in
    If mutable hardware is selected in FCS_CKM_EXT.1.1, FCS_CKM_EXT.7 must be included in the ST. Note that if immutable hardware is selected in FCS_CKM_EXT.1.1
    require the use of certificates to authenticate the remote entity. For example, if the TOE or platform implements TLS as a HTTPS/TLS server with no mutual authentication, X509 authentication is not claimed for TLS. If the TOE or platform operates as a TLS client, X509 authentication must be claimed.
    FIA_X509_EXT.2.2
    When the application cannot establish a connection to determine the validity of a certificate, the application shall [selection: allow the administrator to choose whether to accept the certificate in these cases, accept the certificate, not accept the certificate].
    Application Note: Often a connection must be established to perform a verification of the revocation status of a certificate - either to download a CRL or to perform OCSP. The selection is used to describe the behavior in the event that such a connection cannot be established (for example, due to a network error). If the TOE has determined the certificate valid according to all other rules in FIA_X509_EXT.1, the behavior indicated in the selection shall determine the validity. The TOE must not accept the certificate if it fails any of the other validation rules in FIA_X509_EXT.1.
    Evaluation Activities
    FIA_X509_EXT.2
    TSS
    The evaluator shall check the TSS to ensure that it describes how the TOE chooses which certificates to use, and any necessary instructions in the administrative guidance for configuring the operating environment so that the TOE can use the certificates.

    The evaluator shall examine the TSS to confirm that it describes the behavior of the TOE when a connection cannot be established during the validity check of a certificate used in establishing a trusted channel. The evaluator shall verify that any distinctions between trusted channels are described. If the requirement that the administrator is able to specify the default action, then the evaluator shall ensure that the operational guidance contains instructions on how this configuration action is performed.

    Guidance
    None.

    Tests
    The evaluator shall perform the following test for each trusted channel:
    B.3
    it implicitly meets FCS_CKM_EXT.7.


    The lack of a public/documented API for importing or exporting, when a private/undocumented API exists, is not sufficient to meet this requirement.
    TSS
    The evaluation activity for this component is performed in conjunction with the evaluation activity for FCS_CKM_EXT.1.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    There are no test evaluation activities for this component.

    B.2 Class: User Data Protection (FDP)

    FDP_ACF_EXT.2 Access Control for System Resources

    The inclusion of this selection-based component depends upon selection in FDP_ACF_EXT.1.2.
    The TSF shall provide a separate[selection: address book, calendar, keystore, account credential database, [assignment: list of additional resources ]]for each application group and only allow applications within that process group to access the resource. Exceptions may only be explicitly authorized for such sharing by[selection: the user, the administrator, no one].
    Application Note: If groups of applications is selected in FDP_ACF_EXT.1.2, FDP_ACF_EXT.2 must be included in the ST.
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    For each selected resource, the evaluator shall cause data to be placed into the Enterprise group’s instance of that shared resource. The evaluator shall install an application into the Personal group that attempts to access the shared resource information and verify that it cannot access the information.

    B.3 Class: Protection of the TSF (FPT)

    FPT_

    TUD

    TST_EXT.

    2 Integrity for Installation and Update

    3 TSF Integrity Testing

    The inclusion of this selection-based component depends upon selection in
    FPT
    FIA_
    TUD
    X509_EXT.2.1.
    5.
    TUD
    2
    3.1
    The
    application shall be distributed using the format of the platform-supported package manager.
    FPT_TUD_EXT.2.2
    The application shall be packaged such that its removal results in the deletion of all traces of the application, with the exception of configuration settings, output files, and audit/log events.
    Application Note: Applications software bundled with the system/firmware image are not subject to this requirement if the user is unable to remove the application through means provided by the OS.
    FPT_TUD_EXT.2.3
    The application installation package shall be digitally signed such that its platform can cryptographically verify them prior to installation. Application Note: The specifics of the verification of installation packages involves requirements on the platform (and not the application), so these are not fully specified here
    TSF shall not execute code if the code signing certificate is deemed invalid.
    Application Note: Certificates may optionally be used for code signing for integrity verification (FPT_TST_EXT.2.1/PREKERNEL). If code signing for integrity verification is selected in FIA_X509_EXT.2.1, FPT_TST_EXT.3 must be included in the ST.


    Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280.
    TUD
    2
    None
    There are no TSS evaluation activities for this component.


    Guidance
    None

    Appendix C - Entropy Documentation and Assessment

    This appendix describes the required supplementary information for the entropy source used by the TOE.

    There are no guidance evaluation activities for this component.


    Tests
    The evaluator shall verify that application updates are distributed in the format supported by the platform. This varies per platform:
    Platforms:Android...
    The evaluator shall ensure that the application is packaged in the Android application package (APK) format.
    Platforms:Microsoft Windows...
    The evaluator shall ensure that the application is packaged in the standard Windows Installer (.MSI) format, the Windows Application Software (.EXE) format signed using the Microsoft Authenticode process, or the Windows Universal Application package (.APPX) format. See https://msdn.microsoft.com/en-us/library/ms537364(v=vs.85).aspx for details regarding Authenticode signing.
    Platforms:Apple iOS...
    The evaluator shall ensure that the application is packaged in the IPA format.
    Platforms:Linux...
    The evaluator shall ensure that the application is packaged in the format of the package management infrastructure of the chosen distribution. For example, applications running on Red Hat and Red Hat derivatives shall be packaged in RPM format. Applications running on Debian and Debian derivatives shall be packaged in DEB format.
    Platforms:Oracle Solaris...
    The evaluator shall ensure that the application is packaged in the PKG format.
    Platforms:Apple macOS...
    The evaluator shall ensure that application is packaged in the DMG format, the PKG format, or the MPKG format.
    FPT_TUD_EXT.2.2
    TSS
    None.

    Guidance
    None.

    Tests
    Platforms:Android...
    The evaluator shall consider the requirement met because the platform forces applications to write all data within the application working directory (sandbox).
    Platforms:Microsoft Windows...
    The evaluator shall install the application and then locate all of its executable files. The evaluator shall then, for each file, save off either a hash of the file or a copy of the file itself. The evaluator shall then run the application and exercise all features of the application as described in the ST. The evaluator shall then compare each executable file with the either the saved hash or the saved copy of the files. The evaluator shall verify that these are identical.
    Platforms:Apple iOS...
    The evaluator shall consider the requirement met because the platform forces applications to write all data within the application working directory (sandbox).
    Platforms:Linux...
    The evaluator shall install the application and then locate all of its executable files. The evaluator shall then, for each file, save off either a hash of the file or a copy of the file itself. The evaluator shall then run the application and exercise all features of the application as described in the ST. The evaluator shall then compare each executable file with the either the saved hash or the saved copy of the files. The evaluator shall verify that these are identical.
    Platforms:Oracle Solaris...
    The evaluator shall install the application and then locate all of its executable files. The evaluator shall then, for each file, save off either a hash of the file or a copy of the file itself. The evaluator shall then run the application and exercise all features of the application as described in the ST. The evaluator shall then compare each executable file with the either the saved hash or the saved copy of the files. The evaluator shall verify that these are identical.
    Platforms:Apple macOS...
    The evaluator shall install the application and then locate all of its executable files. The evaluator shall then, for each file, save off either a hash of the file or a copy of the file itself. The evaluator shall then run the application and exercise all features of the application as described in the ST. The evaluator shall then compare each executable file with the either the saved hash or the saved copy of the files. The evaluator shall verify that these are identical.
    FPT_TUD_EXT.2.3
    TSS
    The evaluator shall verify that the TSS identifies how the application installation package is signed by an authorized source. The definition of an authorized source must be contained in the TSS.

    Guidance
    None.

    Tests
    None.

    Testing for this component is performed in conjunction with the Evaluation Activities for FPT_TST_EXT.2.1/PREKERNEL.

    FPT_TUD_EXT.4 Trusted Update Verification

    The inclusion of this selection-based component depends upon selection in FIA_X509_EXT.2.1.
    The TSF shall not install code if the code signing certificate is deemed invalid.
    Application Note: Certificates may optionally be used for code signing of system software updates (FPT_TUD_EXT.2.3) and of mobile applications ( FPT_TUD_EXT.5.1). This element must be included in the ST if certificates are used for either update element. If either code signing for system software updates or code signing for mobile applications is selected in FIA_X509_EXT.2.1, FPT_TUD_EXT.4 must be included in the ST.


    Validity is determined by the certificate path, the expiration date, and the revocation status in accordance with RFC 5280.
    TSS
    There are no TSS evaluation activities for this component.


    Guidance
    There are no guidance evaluation activities for this component.


    Tests
    Testing for this component is performed in conjunction with the Evaluation Activities for FPT_TUD_EXT.2 and FPT_TUD_EXT.5.

    Appendix C - Implicitly Satisfied Requirements

    This appendix lists requirements that should be considered satisfied by products successfully evaluated against this PP. These requirements are not featured explicitly as SFRs and should not be included in the ST. They are not included as standalone SFRs because it would increase the time, cost, and complexity of evaluation. This approach is permitted by [CC] Part 1, 8.2 Dependencies between components.

    This information benefits systems engineering activities which call for inclusion of particular security controls. Evaluation against the PP provides evidence that these controls are present and have been evaluated.

    RequirementRationale for Satisfaction
    FAU_SEL.1 - Selective AuditFAU_SEL.1 has a dependency on FMT_MTD.1 since configuration of audit data is a subset of managing TSF data. This dependency is met by FMT_SMF.1, which defines "configure the auditable items" as a management function and specifies the roles that may perform this, consistent with how FMT_MTD.1 would typically satisfy the dependency.
    FCS_CKM.1 - Cryptographic Key GenerationFCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF generates. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose.
    FCS_CKM.1 - Cryptographic Key GenerationFCS_CKM.1 has a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF generates. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent.
    FCS_CKM.2 - Cryptographic Key EstablishmentBoth iterations of FCS_CKM.2 have a dependency on FCS_CKM.4 for the subsequent destruction of any keys that the TSF establishes. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent.
    FCS_COP.1 - Cryptographic OperationAll iterations of FCS_COP.1 have a dependency on FCS_CKM.4 for the subsequent destruction of any residual key material the TSF creates as part of the operation. This dependency is met by the extended SFR FCS_CKM_EXT.4, which serves the same purpose as its CC Part 2 equivalent.
    FCS_STG_EXT.1 - Cryptographic Key StorageFCS_STG_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.
    FDP_ACF_EXT.1 - Access Control for System ServicesFDP_ACF_EXT.1 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.
    FDP_ACF_EXT.2 - Access Control for System ResourcesFDP_ACF_EXT.2 has a dependency on FMT_SMR.1 for the management roles that are authorized to manage the functionality defined by the requirement. This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.
    FIA_AFL_EXT.1 - Authentication Failure HandlingFIA_AFL_EXT.1 has a dependency on FIA_UAU.1 since handling of authentication failures is not possible without an authentication mechanism. This dependency is met by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent.
    FIA_PMG_EXT.1 - Password ManagementFIA_PMG_EXT.1 has a dependency on FIA_UAU.1 since composition of authentication credentials is not possible without an authentication mechanism. This dependency is met by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent.
    FIA_UAU.7 - Protected Authentication FeedbackFIA_UAU.7 has a dependency on FIA_UAU.1 since protected authentication feedback is not possible without an authentication mechanism. This dependency is met by the extended SFR FIA_UAU_EXT.1, which serves the same purpose as its CC Part 2 equivalent.
    FMT_SMF_EXT.3 - Current AdministratorFMT_SMF_EXT.3 has a dependency on FMT_SMR.1 through its reference to management roles in the requirement text. This dependency is met by FMT_SMF.1, which implicitly defines separate management roles for the TSF.

    Appendix D - Entropy Documentation And Assessment

    The documentation of the entropy source should be detailed enough that, after reading, the evaluator will thoroughly understand the entropy source and why it can be relied upon to provide sufficient entropy. This documentation should include multiple detailed sections: design description, entropy justification, operating conditions, and health testing. This documentation is not required to be part of the TSS.

    C

    D.1 Design Description

    Documentation shall include the design of the entropy source as a whole, including the interaction of all entropy source components. Any information that can be shared regarding the design should also be included for any third-party entropy sources that are included in the product.

    The documentation It will describe the operation of the entropy source to include how it works, how entropy is produced, and how unprocessed (raw) data can be obtained from within the entropy source for testing purposes. The documentation should walk through the entropy source design indicating where the entropy random comes from, where the entropy output it is passed next, any post-processing of the raw outputs (hash, XOR, etc.), if/where it is stored, and finally, how it is output from the entropy source. Any conditions placed on the process (e.g., blocking) should also be described in the entropy source design. Diagrams and examples are encouraged.

    This design must also include a description of the content of the security boundary of the entropy source and a description of how the security boundary ensures that an adversary outside the boundary cannot affect the entropy rate.

    If implemented, the design description shall include a description of how third-party applications can add entropy to the RBG. A description of any RBG state saving between power-off and power-on shall be included.

    C

    D.2 Entropy Justification

    There should be a technical argument for where the unpredictability in the source comes from and why there is confidence in the entropy source delivering sufficient entropy for the uses made of the RBG output (by this particular TOEexhibiting probabilistic behavior (an explanation of the probability distribution and justification for that distribution given the particular source is one way to describe this). This argument will include a description of the expected min- entropy rate (i.e. the minimum entropy (in bits) per bit or byte of source data) and explain how you ensure that sufficient entropy is going into the TOE randomizer seeding process. This discussion will be part of a justification for why the entropy source can be relied upon to produce bits with entropy.

    The amount of information necessary to justify the expected min- entropy rate depends on the type of entropy source included in the product.

    For developer provided entropy sources, in order to justify the min-entropy rate, it is expected that a large number of raw source bits will be collected, statistical tests will be performed, and the min-entropy rate determined from the statistical tests. While no particular statistical tests are required at this time, it is expected that some testing is necessary in order to determine the amount of min-entropy in each output.

    For third party provided entropy sources, in which the TOE vendor has limited access to the design and raw entropy data of the source, the documentation will indicate an estimate of the amount of min-entropy obtained from this third-party source. It is acceptable for the vendor to “assume” an amount of min-entropy, however, this assumption must be clearly stated in the documentation provided. In particular, the min-entropy estimate must be specified and the assumption included in the ST.

    Regardless of type of entropy source, the justification will also include how the DRBG is initialized with the entropy stated in the ST, for example by verifying that the min-entropy rate is multiplied by the amount of source data used to seed the DRBG or that the rate of entropy expected based on the amount of source data is explicitly stated and compared to the statistical rate. If the amount of source data used to seed the DRBG is not clear or the calculated rate is not explicitly related to the seed, the documentation will not be considered complete.

    The entropy justification shall not include any data added from any third-party application or from any state saving between restarts.

    C

    D.3 Operating Conditions

    The entropy rate may be affected by conditions outside the control of the entropy source itself. For example, voltage, frequency, temperature, and elapsed time after power-on are just a few of the factors that may affect the operation of the entropy source. As such, documentation Documentation will also include the range of operating conditions under which the entropy source is expected to generate random data. It will clearly describe the measures that have been taken in the system design to ensure the entropy source continues to operate under those conditions. Similarly, documentation shall describe the conditions under which the entropy source is known to malfunction or become inconsistent. Methods used to detect failure or degradation of the source shall be included.

    C

    D.4 Health Testing

    More specifically, all entropy source health tests and their rationale will be documented. This will include a description of the health tests, the rate and conditions under which each health test is performed (e.g., at startup, continuously, or on-demand), the expected results for each health test, and rationale indicating why each test is believed to be appropriate for detecting one or more failures in the entropy source.

    Appendix

    D - Application Software Equivalency Guidelines

    D.1 Introduction

    The purpose of equivalence in PP-based evaluations is to find a balance between evaluation rigor and commercial practicability—to ensure that evaluations meet customer expectations while recognizing that there is little to be gained from requiring that every variation in a product or platform be fully tested. If a product is found to be compliant with a PP on one platform, then all equivalent products on equivalent platforms are also considered to be compliant with the PP.

    A Vendor can make a claim of equivalence if the Vendor believes that a particular instance of their Product implements PP-specified security functionality in a way equivalent to the implementation of the same functionality on another instance of their Product on which the functionality was tested. The Product instances can differ in version number or feature level (model), or the instances may run on different platforms. Equivalency can be used to reduce the testing required across claimed evaluated configurations. It can also be used during Assurance Maintenance to reduce testing needed to add more evaluated configurations to a certification.

    These equivalency guidelines do not replace Assurance Maintenance requirements or NIAP Policy #5 requirements for CAVP certificates. Nor may equivalency be used to leverage evaluations with expired certifications.

    These Equivalency Guidelines represent a shift from complete testing of all product instances to more of a risk-based approach. Rather than require that every combination of product and platform be tested, these guidelines support an approach that recognizes that products are being used in a variety of environments—and often in cloud environments over where the vendor (and sometimes the customer) have little or no control over the underlying hardware. Developers should be responsible for the security functionality of their applications on the platforms they are developed for—whether that is an operating system, a virtual machine, or a software-based execution environment such as a container. But those platforms may themselves run within other environments—virtual machines or operating systems—that completely abstract away the underlying hardware from the application. The developer should not be held accountable for security functionality that is implemented by platform layers that are abstracted away. The implication is that not all security functionality will necessarily be tested for all platform layers down to the hardware for all evaluated configurations—especially for applications developed for software-based execution environments such as containers. For these cases, the balancing of evaluation rigor and commercial practicability tips in favor of practicability. Note that this does not affect the requirement that at least one product instance be fully tested on at least one platform with cryptography mapped to a CAVP certificate.

    Equivalency has two aspects:

    1. Product Equivalence: Products may be considered equivalent if there are no differences between Product Models and Product Versions with respect to PP-specified security functionality.
    2. Platform Equivalence: Platforms may be considered equivalent if there are no significant differences in the services they provide to the Product—or in the way the platforms provide those services—with respect to PP-specified security functionality.
    The equivalency determination is made in accordance with these guidelines by the Validator and Scheme using information provided by the Evaluator/Vendor.

    D.2 Approach to Equivalency Analysis

    There are two scenarios for performing equivalency analysis. One is when a product has been certified and the vendor wants to show that a later product should be considered certified due to equivalence with the earlier product. The other is when multiple product variants are going though evaluation together and the vendor would like to reduce the amount of testing that must be done. The basic rules for determining equivalence are the same in both cases. But there is one additional consideration that applies to equivalence with previously certified products. That is, the product with which equivalence is being claimed must have a valid certification in accordance with scheme rules and the Assurance Maintenance process must be followed. If a product’s certification has expired, then equivalence cannot be claimed with that product.

    When performing equivalency analysis, the Evaluator/Vendor should first use the factors and guidelines for Product Model equivalence to determine the set of Product Models to be evaluated. In general, Product Models that do not differ in PP-specified security functionality are considered equivalent for purposes of evaluation against the AppPP.

    If multiple revision levels of Product Models are to be evaluated—or to determine whether a revision of an evaluated product needs re-evaluation—the Evaluator/Vendor and Validator should use the factors and guidelines for Product Version equivalence to analyze whether Product Versions are equivalent.

    Having determined the set of Product Models and Versions to be evaluated, the next step is to determine the set of Platforms that the Products must be tested on.

    Each non-equivalent Product for which compliance is claimed must be fully tested on each non-equivalent platform for which compliance is claimed. For non-equivalent Products on equivalent platforms, only the differences that affect PP-specified security functionality must be tested for each product.

    “Differences in PP-Specified Security Functionality” Defined

    If PP-specified security functionality is implemented by the TOE, then differences in the actual implementation between versions or product models break equivalence for that feature. Likewise, if the TOE implements the functionality in one version or model and the functionality is implemented by the platform in another version or model, then equivalence is broken. If the functionality is implemented by the platform in multiple models or versions on equivalent platforms, then the functionality is considered different if the product invokes the platform differently to perform the function.

    D.3 Specific Guidance for Determining Product Model Equivalence

    Product Model equivalence attempts to determine whether different feature levels of the same product across a product line are equivalent for purposes of PP testing. For example, if a product has a “basic” edition and an “enterprise” edition, is it necessary to test both models? Or does testing one model provide sufficient assurance that both models are compliant?

    Product models are considered equivalent if there are no differences that affect PP-specified security functionality—as indicated in Table 1.

    FactorSame/DifferentGuidance
    PP-Specified FunctionalitySameIf the differences between Models affect only non-PP-specified functionality, then the Models are equivalent.
    DifferentIf PP-specified security functionality is affected by the differences between Models, then the Models are not equivalent and must be tested separately. It is necessary only to test the functionality affected by the software differences. If only differences are tested, then the differences must be enumerated, and for each difference the Vendor must provide an explanation of why each difference does or does not affect PP-specified functionality. If the Product Models are separately tested fully, then there is no need to document the differences.
    Table 1. Determining Product Model Equivalence

    D.4 Specific Guidance for Determining Product Version Equivalence

    In cases of version equivalence, differences are expressed in terms of changes implemented in revisions of an evaluated Product. In general, versions are equivalent if the changes have no effect on any security-relevant claims about the TOE or assurance evidence. Non-security-relevant changes to TOE functionality or the addition of non-security-relevant functionality does not affect equivalence.

    FactorSame/DifferentGuidance
    Product ModelsDifferentVersions of different Product Models are not equivalent unless the Models are equivalent as defined in Section 3.
    PP-Specified FunctionalitySameIf the differences affect only non-PP-specified functionality, then the Versions are equivalent.
    DifferentIf PP-specified security functionality is affected by the differences, then the Versions are not considered equivalent and must be tested separately. It is necessary only to test the functionality affected by the changes. If only the differences are tested, then for each difference the Vendor must provide an explanation of why the difference does or does not affect PP-specified functionality. If the Product Versions are separately tested fully, then there is no need to document the differences.
    Table 2. Factors for Determining Product Version Equivalence

    D.5 Specific Guidance for Determining Platform Equivalence

    Platform equivalence is used to determine the platforms that equivalent versions of a Product must be tested on. Platform equivalence analysis done for one software application cannot be applied to another software application. Platform equivalence is not general—it is with respect to a particular application.

    Product Equivalency analysis must already have been done and Products have been determined to be equivalent.

    The platform can be hardware or virtual hardware, an operating system or similar entity, or a software execution environment such as a container. For purposes of determining equivalence for software applications, we address each type of platform separately. In general, platform equivalence is based on differences in the interfaces between the TOE and Platform that are relevant to the implementation of PP-specified security functionality.

    D.5.1 Platform Equivalence—Hardware/Virtual Hardware Platforms

    If an Application runs directly on hardware without an operating system—or directly on virtualized hardware without an operating system—then platform equivalence is based on processor architecture and instruction sets. In the case of virtualized hardware, it is the virtualized processor and architecture that are presented to the application that matters—not the physical hardware.

    Platforms with different processor architectures and instruction sets are not equivalent. This is not likely to be an issue for equivalency analysis for applications since there is likely to be a different version of the application for different hardware environments. Equivalency analysis becomes important when comparing processors with the same architecture. Processors with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified from being equivalent for purposes of an App evaluation. If the application takes the same code paths when executing PP-specified security functionality on different processors of the same family, then the processors can be considered equivalent with respect to that application. For example, if an application follows one code path on platforms that support the AES-NI instruction and another on platforms that do not, then those two platforms are not equivalent with respect to that application functionality. But if the application follows the same code path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality.

    The platforms are equivalent with respect to the application if the platforms are equivalent with respect to all PP-specified security functionality.
    FactorSame/Different/NoneGuidance
    Platform ArchitecturesDifferentPlatforms that present different processor architectures and instruction sets to the application are not equivalent.
    PP-Specified FunctionalitySameFor platforms with the same processor architecture, the platforms are equivalent with respect to the application if execution of all PP-specified security functionality follows the same code path on both platforms.
    Table 3. Factors for Determining Hardware/Virtual Hardware Platform Equivalence

    D.5.2 Platform Equivalence—OS Platforms

    For traditional applications that are built for and run on operating systems, platform equivalence is determined by the interfaces between the application and the operating system that are relevant to PP-specified security functionality. Generally, these are the processor interface, device interfaces, and OS APIs. The following factors applied in order:
    FactorSame/Different/NoneGuidance
    Platform ArchitecturesDifferentPlatforms that run on different processor architectures and instruction sets are not equivalent.
    Platform VendorsDifferentPlatforms from different vendors are not equivalent.
    Platform VersionsDifferentPlatforms from the same vendor with different major version numbers are not equivalent.
    Platform InterfacesDifferentPlatforms from the same vendor and major version are not equivalent if there are differences in device interfaces and OS APIs that are relevant to the way the platform provides PP-specified security functionality to the application.
    Platform InterfacesSamePlatforms from the same vendor and major version are equivalent if there are no differences in device interfaces and OS APIs that are relevant to the way the platform provides PP-specified security functionality to the application, or if the Platform does not provide such functionality to the application.
    Table 4. Factors for Determining OS/VS Platform Equivalence

    D.5.3 Software-based Execution Environment Platform Equivalence

    If an Application is built for and runs in a non-OS software-based execution environment, such as a Container or Java Runtime, then the below criteria must be used to determine platform equivalence. The key point is that the underlying hardware (virtual or physical) and OS is not relevant to platform equivalence. This allows applications to be tested and run on software-based execution environments on any hardware—as in cloud deployments.
    FactorSame/Different/NoneGuidance
    Platform Type/VendorDifferentSoftware-based execution environments that are substantially different or come from different vendors are not equivalent. For example, a java virtual machine is not the same as a container. A Docker container is not the same as a CoreOS container.
    Platform VersionsDifferentExecution environments that are otherwise equivalent are not equivalent if they have different major version numbers.
    PP-Specified Security FunctionalitySameAll other things being equal, execution environments are equivalent if there is no significant difference in the interfaces through which the environments provide PP-specified security functionality to applications.
    Table 5. Factors for Software-based Execution Environment Platform Equivalence

    D.6 Level of Specificity for Tested Configurations and Claimed Equivalent Configurations

    In order to make equivalency determinations, the vendor and evaluator must agree on the equivalency claims. They must then provide the scheme with sufficient information about the TOE instances and platforms that were evaluated, and the TOE instances and platforms that are claimed to be equivalent.

    The ST must describe all configurations evaluated down to processor manufacturer, model number, and microarchitecture version.

    The information regarding claimed equivalent configurations depends on the platform that the application was developed for and runs on.

    Bare-Metal Applications

    For applications that run without an operating system on bare-metal or virtual bare-metal, the claimed configuration must describe the platform down to the specific processor manufacturer, model number, and microarchitecture version. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE functions differently to leverage platform differences (e.g., instruction set extensions) in the tested configuration versus the claimed equivalent configuration.

    Traditional Applications

    For applications that run with an operating system as their immediate platform, the claimed configuration must describe the platform down to the specific operating system version. If the platform is a virtualization system, then the claimed configuration must describe the platform down to the specific virtualization system version. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE functions differently to leverage platform differences in the tested configuration versus the claimed equivalent configuration. Relevant platform differences could include instruction sets, device interfaces, and OS APIs invoked by the TOE to implement PP-specified security functionality.

    Software-Based Execution Environments

    For applications that run in a software-based execution environment such as a Java virtual machine or a Container, then the claimed configuration must describe the platform down to the specific version of the software execution environment. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE functions differently to leverage platform differences in the tested configuration versus the claimed equivalent configuration.

    Appendix E - Acronyms

    AcronymMeaning ADBAndroid Debug Bridge AESAdvanced Encryption Standard ANSIAmerican National Standards Institute APIApplication Programming Interface APKAndroid Application Package APPXWindows Universal Application Package ASLRAddress Space Layout Randomization BIOSBasic Input/Output System

    E - Acronyms

    Table 9: Acronyms
    AcronymMeaning
    Base-PPBase Protection Profile
    CCCommon Criteria
    CEMCommon Evaluation Methodology
    CMCCertificate Management over CMS
    CMSCryptographic Message Syntax
    CNCommon Names
    CRLCertificate Revocation List
    CSAComputer Security Act
    DEPData Execution Prevention
    DESData Encryption Standard
    DHEDiffie-Hellman Ephemeral
    DMGApple Disk Image
    DNSDomain Name System
    DPAPIData Protection Application Programming Interface
    DRBGDeterministic Random Bit Generator
    DSSDigital Signature Standard
    DTDate/Time Vector
    DTLSDatagram Transport Layer Security
    EAPExtensible Authentication Protocol
    ECDHEElliptic Curve Diffie-Hellman Ephemeral
    ECDSAElliptic Curve Digital Signature Algorithm
    ELFExecutable and Linkable Format
    EMETEnhanced Mitigation Experience Toolkit
    ESTEnrollment over Secure Transport
    FIPSFederal Information Processing Standards
    GPSGlobal Positioning System
    HMACHash-based Message Authentication Code
    HTTPHypertext Transfer Protocol
    HTTPSHypertext Transfer Protocol Secure
    IANAInternet Assigned Number Authority
    IECInternational Electrotechnical Commission
    IETFInternet Engineering Task Force
    IPInternet Protocol
    IPAiOS Package archive
    IRIntermediate Integer
    ISOInternational Organization for Standardization
    ITInformation Technology
    ITSEFInformation Technology Security Evaluation Facility
    JNIJava Native Interface
    LDAPLightweight Directory Access Protocol
    MIMEMulti-purpose Internet Mail Extensions
    MPKGMeta Package
    MSIMicrosoft Installer
    NFCNear Field Communication
    NIAPNational Information Assurance Partnership
    NISTNational Institute of Standards and Technology
    OCSPOnline Certificate Status Protocol
    OEOperational Environment
    OIDObject Identifier
    OMBOffice of Management and Budget
    OSOperating System
    PDFPortable Document Format
    PEPortable Executable
    PIDProcess Identifier
    PIIPersonally Identifiable Information
    PKGPackage file
    PKIPublic Key Infrastructure
    cPPCollaborative Protection Profile
    EPExtended Package
    FPFunctional Package
    OEOperational Environment
    PPProtection Profile
    PP-ConfigurationProtection Profile Configuration
    PP-ModuleProtection Profile Module
    RBGRandom Bit Generator
    RFCRequest for Comment
    RNGRandom Number Generator
    RNGVSRandom Number Generator Validation System
    S/MIMESecure/Multi-purpose Internet Mail Extensions
    SANSubject Alternative Name
    SARSecurity Assurance Requirement
    SESecurity Enhancements
    SFRSecurity Functional Requirement
    SHASecure Hash Algorithm
    SIPSession Initiation Protocol
    SPSpecial Publication
    SSHSecure Shell
    STSecurity Target
    SWIDSoftware Identification
    TLSTransport Layer Security
    TOETarget of Evaluation
    TSFTOE Security Functionality
    TSFITSF Interface
    TSSTOE Summary Specification
    UIUser Interface
    URIUniform Resource Identifier
    URLUniform Resource Locator
    USBUniversal Serial Bus
    XCCDFeXtensible Configuration Checklist Description Format
    XORExclusive Or
    appApplication
    cPPCollaborative Protection Profile

    Appendix F - Bibliography

    Table 10: Bibliography
    IdentifierTitle
    [CC]Common Criteria for Information Technology Security Evaluation -
    [CEM] Common Evaluation Methodology for Information Technology Security - Evaluation Methodology, CCMB-20172012-0409-004, Version 3.1, Revision 5, April 2017.
    [OMB] Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, OMB M-06-19, July 12, 2006.

    Appendix G - Acknowledgments

    This protection profile was developed by the Mobility Technical Community with representatives from industry, U.S. Government agencies, Common Criteria Test Laboratories, and international Common Criteria schemes. The National Information Assurance Partnership wishes to acknowledge and thank the members of this group whose dedicated efforts contributed significantly to the publication. These organizations include:


    U.S. Government

    Defense Information Systems Agency (DISA)

    CyberSecurity Directorate (CSD)

    National Information Assurance Partnership (NIAP)

    National Institute of Standards and Technology (NIST)


    International Common Criteria Schemes

    Australian Information Security Evaluation Program (AISEP)

    Canadian Common Criteria Evaluation and Certification Scheme (CSEC)

    Information-technology Promotion Agency, Japan (IPA)

    UK IT Security Evaluation and Certificate Scheme (NCSC)


    Industry

    Apple, Inc.

    BlackBerry

    LG Electronics, Inc.

    Microsoft Corporation

    Motorola Solutions

    Samsung Electronics Co., Ltd.

    Other Members of the Mobility Technical Community


    Common Criteria Test Laboratories

    EWA-Canada, Ltd.

    Gossamer Security Solutions